Why Your Site Is Slow for Indian Users Even Though It Scores 95

Your site scores 95. Someone in Nagpur still waits four seconds and leaves. Both things are true, and the reason is that the test and the user have almost nothing in common.

Three things cause most of the gap: the test device is faster than the real one, the test connection is more consistent than the real one, and the server is further from the user than from the test runner. None of them show up on the score.

Who is actually visiting an Indian website?

Worth grounding this in numbers rather than impressions. At the end of August 2026 India had 1,101 million broadband subscriptions, of which only 48.63 million were fixed wired connections — DSL, fibre, Ethernet or cable — according to TRAI's monthly subscription data. Essentially everything else is mobile. The same release puts 42.15% of wireless subscribers in rural areas.

On devices, Android holds about 93.9% of India's mobile OS share and iOS about 6% as of September 2026. And the most common mobile screen resolution in the country is 360×800 CSS pixels, which is a mid-range phone, not a flagship.

So the median Indian visitor is on an Android phone, on mobile data, on a screen narrower than most designers' breakpoint, quite possibly on a train. If your performance work was validated on a MacBook over office fibre, you have optimised for a visitor who barely exists in your traffic.

Why is a 95 from a foreign test location not a lie, just irrelevant?

Lighthouse does throttle. Its default mobile profile models a 150ms round trip, 1.6 Mbps down, 750 Kbps up, and a 4× CPU slowdown. That is a reasonable stand-in for a congested 4G connection, and it is better than no throttling at all.

Three things about it matter.

The CPU multiplier is relative. It slows the machine running the test by 4×. On a fast laptop that lands somewhere near a decent mid-range phone. On an already-fast CI runner it lands near a flagship, and on a loaded shared runner it can simulate something slower than anything on sale. The same code gets different scores depending on what measured it.

The latency is modelled, not travelled. A 150ms simulated round trip from a server in the US is not the same as a real 150ms round trip to a server in the US. Simulated throttling applies a model on top of one unthrottled load, so it does not reproduce TCP slow start, packet loss, or the way a weak mobile signal collapses and recovers. Real mobile networks are not slow so much as inconsistent, and inconsistency is the part no simulation captures.

The default run tests one page, cold, with no user. No cache, no third-party consent state, nobody tapping anything. Google's own guidance is that lab data tells you why and field data tells you whether.

There is a subtler trap in the field data too. CrUX, the dataset behind PageSpeed Insights' field section and Search Console, only collects from Chrome on desktop and Android — not Chrome on iOS, and not Android WebViews. In India a large share of traffic arrives through in-app browsers inside WhatsApp, Instagram and news apps, which are WebViews. Those sessions are usually the slowest on your site and they are invisible in CrUX. Your own analytics will show them; Google's field data will not.

How far away is your server, really?

This is the part people skip, and it is often the single largest line item.

Google's LCP breakdown suggests Time to First Byte should be about 40% of LCP. If you are aiming at 2.5 seconds, that is roughly a one-second budget for the first byte — and distance eats it fast.

The arithmetic is unforgiving. Light in optical fibre travels at roughly 200 km per millisecond. Mumbai to Washington DC is about 12,500 km, so a single round trip has a floor near 125ms before any router, any queue, or any work on the server. Real routes are longer than great-circle distance. Now count the round trips: one for the TCP handshake, one for the TLS handshake, one for the request itself. Three round trips at a realistic 250ms each is 750ms gone before your application has done anything at all.

That is why a CDN helps and why it does not help as much as people assume. CDNs have genuinely good Indian coverage now — CloudFront lists Bengaluru, Chennai, Hyderabad, Kolkata, Mumbai, New Delhi and Pune as points of presence, plus dozens of embedded PoPs in smaller cities. But a point of presence serves cached responses from nearby. An uncached, dynamic, personalised response still travels to wherever your compute lives.

And the compute default catches a surprising number of teams. Vercel operates 126 points of presence but only 19 compute-capable regions, one of which is bom1 in Mumbai — while Vercel Functions default to iad1, Washington DC, unless you change it. The same docs note that TCP terminates at the PoP but TLS termination and compute happen in the region. So a Mumbai PoP absorbs part of the handshake cost and then forwards your user's request across the Indian Ocean to Virginia, where the database probably also lives.

Change	What it fixes	Typical effect
CDN with Indian PoPs	Static assets, cached HTML	Large, and usually already done
Moving compute to Mumbai	Uncached and dynamic responses	Large if your traffic is Indian
Moving the database next to compute	Per-query round trips, which multiply	Often the biggest single win
Caching dynamic pages at the edge	Turns a region round trip into a PoP hit	Large where content allows it
Compressing images further	Resource load duration	Small once you are on modern formats

The row people get wrong is the third. One page doing eight sequential database queries across a 250ms link is two seconds of waiting that no image optimisation touches. Compute and data belong in the same region, and that region should be the one your users are in.

What are third-party scripts and fonts really costing?

Third parties are not a side issue. The 2024 Web Almanac found about 92% of pages use at least one third party, with a median of 27 of them on top-million sites.

Each one typically means a fresh DNS lookup, a TCP handshake and a TLS handshake to a host you do not control, then JavaScript that runs on the main thread of a phone with a fraction of your laptop's single-core speed. On a 4× slower CPU, a tag manager that costs 80ms on a desktop costs well over 300ms, and it costs it during the exact window when the user is first trying to tap something.

Fonts deserve a specific mention because the received wisdom is out of date. Loading Google Fonts from Google's CDN was once nearly free, on the theory that the visitor already had the file cached from another site. That stopped being true in Chrome 86, which partitioned the HTTP cache by top-level site for privacy reasons. A font cached on one site is no longer reused on yours. Every visitor downloads it again, after an extra connection to a third-party host.

So: self-host your fonts, subset them to the characters you use, preload the one or two weights that appear above the fold, and set font-display: swap with a metrics-matched fallback so the swap does not shift your layout. If you serve Indic scripts, subsetting matters more, not less — Devanagari and Telugu font files are substantially larger than Latin ones.

How do I test as an Indian user?

Five steps, in order of how much truth they give you per minute spent.

1. Look at your own field data, split by geography and connection. Real sessions from real Indian users beat every synthetic test. If you have nothing installed, install something today; you will spend the next month guessing otherwise.
2. Run PageSpeed Insights and read only the field section first. It is real Chrome users at the 75th percentile. Treat the lab half as a debugging aid for whatever the field half flagged.
3. Test from an Indian location. WebPageTest has a Mumbai test agent, so the round trips in the result are real ones rather than modelled ones. Avoid its Lighthouse audit option for this, since that runs a fixed connection profile independent of your test settings.
4. Use an actual mid-range Android. Not a flagship, not an emulator. Remote-debug it over USB from Chrome DevTools, on mobile data rather than office Wi-Fi, and open the page from a WhatsApp message so you get the WebView rather than Chrome. This test finds things no tool reports.
5. Watch someone use it. Hand the phone to a colleague who has not seen the page and give them a task. Interaction delays that a metric averages away are obvious within ten seconds of watching a person tap twice because nothing happened the first time.

Step four is the one teams skip and the one that changes minds. A ₹15,000 phone two years old, on 4G in a basement, is your actual production environment.

What to cut first, and what is theatre

In rough order of return:

1. The third-party scripts nobody owns. List every tag, name the person who needs it, and delete the ones with no name against them. There is always at least one analytics tool nobody has opened in a year.
2. JavaScript shipped for pages that do not need it. A content page that ships an entire interactive bundle to render static text is paying CPU cost on a phone for nothing.
3. Compute and database distance. See above. This is config, not a rewrite.
4. Images. Correct dimensions, modern formats, and sized for a 360px-wide viewport rather than a desktop one — the 2× retina asset for a 1200px hero is wasted bytes on the phone that most of your users hold.
5. Fonts. Self-hosted, subset, two weights maximum.

Now the theatre, which is more popular than any of the above.

Chasing the last ten Lighthouse points. Past "good" on the real metrics, you are optimising a test runner's opinion. The thresholds are pass/fail at the 75th percentile and there is no prize above them.

Minifying and concatenating as a headline fix. It is table stakes, your build already does it, and it saves kilobytes in a situation where you are losing seconds to round trips.

Preloading everything. Preload is a priority instruction. Preloading twelve resources tells the browser nothing is important and can make LCP worse by starving the one resource that mattered.

Switching frameworks to fix a config problem. A rewrite because a page is slow, when the page is slow because the function runs in Virginia and the database sits in Mumbai, is an expensive way to avoid changing one line of configuration. Diagnose before you migrate.

Lazy-loading above the fold. Lazy-loading the hero image is the most common self-inflicted LCP failure there is.

Where this leaves the stack

This is the plain reason we build on Next.js and deploy to edge infrastructure rather than putting an Indian audience on a shared host in another country. Server-rendered HTML means the phone's CPU is not on the critical path for first paint; a framework with real image and font primitives means the defaults are already close to right; and a platform with a Mumbai region means the compute and the data can sit where the users are. None of that is exotic, and none of it is a substitute for deleting the four scripts you do not need.

It matters most where the page is doing a job rather than making an impression. When we built the platform for Lynk Labs, a diagnostics business serving 50,000-plus customers with under-24-hour report turnaround, the page that had to be fast was the one a patient opens on their phone to read a result — often on mobile data, often immediately, often while anxious. A marketing homepage can afford a slow second. That page cannot.

If you want the specifics of how we build, they are on the web development page, and what it costs is set out in website development pricing in India.

When none of this applies

If your audience is not in India, ignore the geography and keep your compute near whoever your users actually are. If your traffic is overwhelmingly desktop on corporate networks — some B2B SaaS genuinely is — the mid-range Android argument is not your problem; check before assuming it is.

And if your field data already says all three Core Web Vitals are good at the 75th percentile on mobile, performance is not your bottleneck. Go and look at the form instead. Sites lose far more money to a checkout that asks for a landline number than to 200ms of TTFB.

If you suspect the gap between your score and your users is real but you cannot prove where it is, send us the URL. We will test it from India on a real phone and tell you what we find, including the fairly common answer that the site is fine and the problem is somewhere else entirely.