Images straight from a phone
A 4000 pixel photograph displayed at 800 is the single most common cause we find. The browser downloads all four thousand pixels. Modern formats and correct sizing routinely halve page weight in an afternoon.
Delhi NCR
Website speed optimisation in Delhi measured on the phones people use.
Most speed advice is a list of thirty things. This is the order that fixes the most, and how to tell which one your site is stuck on.
Overview
What actually makes Indian business sites slow
The fastest route to a faster site is usually image compression and sizing, removing unused third-party scripts, caching with a CDN, then fixing render-blocking CSS and fonts. On most Indian business sites those four account for the majority of load time, and hosting response time is the fifth. Measure with Search Console field data, not a Lighthouse screenshot.
Third-party scripts nobody reads
Analytics, tag manager, chat widget, heatmap, two ad pixels and a review widget. Each runs on your visitor's device. Audit what you load and remove what informs no decision. This is the highest return per hour of any speed work and costs nothing.
Cheap shared hosting
If the server takes 800 milliseconds to send the first byte, no front-end work rescues the page. Time to First Byte under 600 milliseconds is a reasonable target, and a lot of low-cost Indian hosting cannot reach it under load.
Page builders
Elementor, Divi and similar ship large CSS and JavaScript payloads on every page regardless of what the page contains. Sometimes the honest answer is that the builder is the problem.
No CDN
Serving every asset from one origin server to visitors across India adds latency you do not need to pay. A CDN is cheap and helps almost every site.
Fonts that block rendering
Four weights of two families, loaded in a way that leaves text invisible while they download. Subset, self-host, use font-display swap, preload the one that matters.
What to avoid
The order we work in
| Step | Typical gain | Effort |
|---|---|---|
| Compress and resize images | Large | Low |
| Remove unused third-party scripts | Large | Low |
| Caching and a CDN | Medium to large | Low |
| Fix render-blocking CSS and fonts | Medium | Medium |
| Defer or split JavaScript | Medium | Medium |
| Better hosting | Medium | Low effort, some cost |
| Rebuild the front end | Large | High |
Work top down and stop when you hit the target. Teams that start at the bottom spend the most and often finish slower than teams that did the first three properly.
Detail
What to ask before you hire
| Ask them | A good answer sounds like | Walk away if |
|---|---|---|
| Who owns the work and files? | You do, unconditionally, in the contract | Ownership depends on staying with them |
| Can I see three live examples? | URLs you can open and check yourself | Screenshots and a portfolio PDF |
| What is explicitly not included? | A written list with change pricing agreed | Everything is included, which means nothing is defined |
| How will we know it worked? | A metric agreed before the work starts | They show you the visuals again |
The last question is the one that separates most of the field, because answering it commits them to a number.
Comparison
Measuring it properly
| Lab data | Field data | |
|---|---|---|
| Where from | PageSpeed Insights, Lighthouse | Chrome User Experience Report |
| What it is | One simulated load from a data centre | Real visitors over 28 days |
| Feeds ranking | No | Yes |
| Good for | Debugging a specific page | Knowing whether you actually pass |
| Common mistake | Treating the score as the goal | Ignoring it because the score looked fine |
This is the source of most arguments between a business owner and their developer. Both are looking at real numbers that measure different things. The one tied to ranking is in Search Console.
FAQ
Common questions
Why is my website slow?
On most sites we audit it is oversized images first, third-party scripts second, and hosting third. A page builder is often a contributing fourth. The fix order matters, because starting with the expensive options usually produces less improvement than starting with images.
What is a good page load time?
Aim for Largest Contentful Paint under 2.5 seconds on mobile, measured on real visitor data rather than a simulated test. Total load time is less useful because it includes work that happens after the page is usable.
Will a caching plugin fix it?
It helps and it does not fix an oversized image problem or twelve third-party scripts. Caching reduces server work. It does nothing about what the browser has to download and execute once the page arrives.
Is my hosting the problem?
If Time to First Byte is above roughly 600 milliseconds, largely yes, and better hosting is usually the cheapest meaningful improvement available. If TTFB is already low, hosting will change very little.
Does site speed affect Google rankings?
Yes, modestly. Core Web Vitals are part of page experience and act more as a tiebreaker than a primary factor. The stronger argument is commercial: slow pages lose visitors before they see anything, which shows up in conversions long before rankings.
Do I need to rebuild the site to make it fast?
Rarely. Most sites reach acceptable numbers through images, script removal, caching and font loading. A rebuild is justified when the weight comes from the theme or page builder itself, which is common on builder-based sites.
How long does speed work take?
One to three weeks for most sites, and you usually see the largest improvement in the first few days from images and scripts alone. Field data in Search Console takes about four weeks to reflect the change, which is why teams often think a fix failed when it has simply not aggregated yet.
How do I know it worked?
Compare Core Web Vitals field data in Search Console before and after, allowing four weeks for the rolling window. Also watch bounce and conversion on your busiest mobile pages, because that is where the commercial effect shows up.
Next step
Tell us what you need.
Send us what you are trying to fix and we will tell you what it takes, what it costs, and whether we are the right people for it. If we are not, we will say so.