Site Speed Doesn't Rank You. It Decides Who Stays

Every few months a client forwards us a screenshot of a speed test with a red score and a subject line that says something like "is this why we are not ranking?". Almost always, no. Almost always, something more expensive than rankings is going wrong, and the speed test is pointing at it sideways.

There are two separate arguments for making a website fast. One is a ranking argument. It is real, it is documented, and it is small. The other is a revenue argument, and it is much larger. Most of the money spent on speed work in India is justified with the first argument and paid back by the second. Knowing which is which changes what you buy.

What Google has actually said

Google publishes a set of measurements it calls Core Web Vitals — three numbers that describe how a page feels to a real person loading it. Google has confirmed these form part of its page experience signals, and that page experience is used in ranking. That much is documented and not in dispute.

What Google has also said, repeatedly and in its own help documentation, is that great page experience does not override having the most relevant content. If a slow page answers the query better than a fast one, the slow page can still win. Speed behaves more like a deciding vote between pages that are otherwise close than like a lever you pull to climb.

Beyond that, be suspicious of confidence. Nobody outside Google knows the weight these signals carry, whether it varies by query type, or how it interacts with everything else. Anyone quoting you a percentage improvement in rankings from a speed fix is making it up. The honest position is: it counts, it counts less than relevance and links, and the exact amount is unknown.

The three numbers and their thresholds

These are Google's published boundaries. They are checkable, unlike most things written about speed.

Measurement	What it means in plain terms	Good	Poor above
Largest Contentful Paint (LCP)	How long until the main thing on screen — usually the big image or headline — actually appears	2.5 seconds or less	4 seconds
Interaction to Next Paint (INP)	When someone taps a menu or a button, how long before the page visibly responds	200 milliseconds or less	500 milliseconds
Cumulative Layout Shift (CLS)	How much the page jumps about while loading, so you tap the wrong thing	0.1 or less	0.25

One important detail that almost nobody explains to business owners: Google's ranking signals use field data — measurements from real Chrome users who visited your site — not the score you get from running a test on your laptop. That test is a simulation on a machine in a data centre. The two can disagree wildly. A site can score 95 in the lab and fail in the field because your actual visitors are on a four-year-old Android handset on patchy mobile data in Laxmi Nagar, not on fibre.

If your site has enough traffic, the field data is visible free in Google Search Console under Core Web Vitals. That is the report worth reading. The colourful lab score is a diagnostic tool, not a grade.

The bigger loss is the person who left

Here is the argument that actually matters.

A ranking signal affects whether you appear. Speed affects whether the person who already clicked stays long enough to read anything. That second group has already been paid for — through ad spend, through months of SEO, through a WhatsApp forward or a hoarding. Losing them is the expensive loss.

Think about the physical behaviour. Someone taps your result while standing in a queue. The screen stays white. They do not think "this site has a large JavaScript bundle". They go back and tap the next result, which is your competitor. Nothing in your analytics shouts about this — you often see it as a suspiciously high bounce rate on mobile, or a page that gets good traffic and produces no enquiries.

The effect is worst exactly where it hurts most. Paid traffic lands on a page and the meter is running. Local searches happen on mobile, outdoors, on the move. And a checkout or enquiry form that stalls after the tap is a sale already half-made and then dropped.

So the sensible framing is: treat speed as conversion work that happens to have a small SEO benefit attached. If you justify it only as SEO, you will over-invest in chasing a perfect score and under-invest in the three or four pages where money actually changes hands.

What actually makes Indian sites slow

In our experience the causes repeat, and they are unglamorous.

• Unprocessed photographs. A picture straight off a phone is often three to five megabytes and four thousand pixels wide, displayed in a box six hundred pixels wide. Ten of those on a gallery page is a catastrophe on mobile data. Resizing and converting to modern formats costs nothing and usually fixes LCP by itself.
• Homepage sliders. A rotating banner loads several large images before anything is readable, and research on what visitors actually click has never been kind to them. They exist because the client asked for them.
• Plugin and script accumulation. A chat widget, a popup tool, two analytics tags, a review badge, a font library, an animation library. Each is small. Together they are the reason the page freezes for a second when someone taps the menu — that is your INP.
• Cheap shared hosting. If the server takes a second and a half to send the first byte, no amount of front-end tuning saves you. This is often the single cheapest fix available.
• Page builders left unrestrained. Drag-and-drop builders are fine until a page has forty nested sections, at which point the page ships enormous amounts of code to render a heading and a form.
• Ads and embeds. Third-party content injected after load is the usual cause of the page jumping while you are reading — the CLS problem.

What we would not buy

Plenty is sold in this category that we would not spend our own money on.

A "100/100 PageSpeed guarantee". The lab score is not the ranking input and a perfect score on a test rig proves nothing about your customer on a mid-range phone in Ghaziabad. It is also achievable by stripping out things you need, such as your tracking or your chat, which quietly costs you more than the score gains.

A caching plugin sold as the whole fix. Caching helps a great deal with repeat server work. It does nothing about a four-megabyte hero image or a theme that loads six fonts. Selling a caching plugin as speed optimisation is selling one screw as a chair.

Monthly "speed maintenance" with no defined work. Speed is mostly a fixed project followed by discipline: don't upload raw photos, don't add a script without asking what it costs. A recurring fee with no scope attached is rent.

Rebuilding a site purely because it is slow. Sometimes right, often not. If the content and structure are sound, image handling, hosting and script pruning usually get you inside the thresholds for a fraction of a rebuild. A rebuild is justified when the site is also failing you commercially — then it is a web development decision, not a speed one.

A sensible order of work

1. Open Search Console and look at the Core Web Vitals report. That is real visitors, not a simulation.
2. Identify your three or four money pages — the ones ads land on, the main service or product pages, the enquiry form, the checkout. Fix those first and completely.
3. Deal with images. Resize, compress, convert. This is usually the largest single gain per rupee.
4. Check server response time. If the first byte is slow, upgrade hosting before touching anything else.
5. Audit third-party scripts. For each one, ask what it earns. Remove what does not earn.
6. Only then chase the last few hundred milliseconds — and only if the pages are commercially important.

What to do next

Take the page you send your paid traffic to, load it on your own phone on mobile data, and count the seconds until you can read the headline and tap the button. That single test tells you more than most reports. If it is uncomfortable, the fix is usually images and hosting, and it is usually not a rebuild.

If you want someone to look at the field data and tell you plainly which of the six causes above applies to you, our technical support and SEO teams do this together, because the answer is nearly always part hosting and part content. Send us the URL and we will tell you what we would do and what we would leave alone.

Questions we get asked