The three numbers, in plain terms
Google measures three things. Stripped of jargon they are simple questions about experience.
- LCP — how long until the main thing appears? Usually the hero image or headline. Target: under 2.5 seconds.
- INP — when someone taps, how long until something happens? This replaced the old FID metric and is far less forgiving. Target: under 200 milliseconds.
- CLS — does the layout jump while loading? Everyone has tapped the wrong thing because an ad or image pushed the page down. Target: under 0.1.
Why the Indian context changes the priorities
Two things differ from the assumptions baked into most performance advice. Devices skew mid-range, which affects INP most, because JavaScript execution is CPU-bound and a cheaper phone simply takes longer. And connections vary, which affects LCP — not because bandwidth is low but because latency is inconsistent.
The practical consequence: JavaScript weight hurts you more here than the same site would hurt a user in a market with newer devices. Cutting scripts is usually the highest-leverage fix available.
What actually moves the numbers
In rough order of impact for a typical business site:
- Serve images properly. Modern formats, correctly sized, with explicit width and height. Oversized images are the most common single cause of poor LCP — and the height attribute alone fixes a large share of CLS.
- Remove JavaScript you do not need. Every library is CPU time on a mid-range phone. Question anything loaded on every page for a feature used on one.
- Cut third-party scripts. Chat widgets, analytics, ad tags, font loaders. Each is a request to someone else's server whose performance you do not control.
- Reserve space for anything that loads late. Embeds, banners and images that arrive after first paint should occupy their final dimensions from the start.
The uncomfortable part
Most of this is far easier to get right at build time than to retrofit. Retrofitting performance onto a theme-based site means fighting decisions someone else made — and there is a floor below which you cannot go without replacing the theme entirely.
That is the honest argument for building custom, and it is a performance argument rather than an aesthetic one. A custom build contains only what your business needs, which is why it starts fast and stays fast.
How to actually measure it
Run PageSpeed Insights, but read the field data section rather than the lab score. Field data is what real users experienced; the lab score is a simulation. A site can score well in the lab and still fail for actual customers on real devices.
Then test on a real mid-range phone on mobile data, not on office WiFi. It takes two minutes and is consistently more informative than any tool.