Your Lighthouse score is lying to you about Indian mobile
A 96 in the lab and a failing Core Web Vitals assessment in the field is the most common performance situation we walk into.
· 5 min read · Web & CRO
Lighthouse runs on a simulated mid-tier device with a throttled connection. Chrome User Experience Report data comes from actual visitors on actual phones on actual networks. In India those two things diverge badly, because the median device is slower than the simulation and the median connection is less stable.
Where the gap comes from
- Third-party scripts that load fine on a fibre connection and block for two seconds on a congested tower.
- Fonts that swap late, pushing layout around after the user has started reading.
- Hero images served at desktop dimensions to a 360px screen.
- Interaction handlers that were never tested on a device with a slow main thread, which is what INP actually measures.
Optimise for the phone your customer has, not the phone your developer has.
What to measure instead
Use the Chrome UX Report data in Search Console as the source of truth, and treat Lighthouse as a debugging tool rather than a scoreboard. Segment field data by device class if you can. The aggregate number often hides a top-end device population passing comfortably and a mid-range population failing badly.
The fixes that actually moved things for us
- A hard budget on third-party scripts, enforced in CI, with a named owner for every one that survives.
- Self-hosted fonts with size-adjust set so the fallback occupies the same space.
- Explicit width and height on every image, which costs nothing and removes most layout shift.
- Breaking up long tasks so the main thread is free when a user taps something.
None of that is exotic. It is unglamorous engineering work, and it is worth more to most sites than another quarter of content.
