Core Web Vitals, and why speed decides more than rankings
Core Web Vitals are Google's attempt to measure how a page feels to use, rather than how fast a server responds.
They are a ranking factor, though a modest one — content and links matter more. The larger effect is behavioural: people abandon slow pages, and abandonment is invisible in most reports because those visitors never reach anything you measure.
The three metrics, plainly
Each measures a different kind of frustration.
- LCP — how long until the main content appears. Aim under 2.5 seconds.
- INP — how quickly the page responds when you interact with it. Aim under 200 milliseconds.
- CLS — how much the layout jumps around while loading. Aim under 0.1.
Why this matters more in India
Performance advice is often written for fast devices on good connections, where poor scores are barely noticeable.
A large share of Indian buyers browse on mid-range Android phones over mobile data. A page that takes 1.2 seconds on a developer's laptop can take five or six seconds in that context. That is not a slightly worse experience; it is a different one, and many people simply leave.
Test on a real mid-range phone on mobile data, not on your laptop on office wifi. The gap is routinely larger than people expect.
What usually causes bad LCP
Almost always one of three things: an oversized hero image, a font that blocks rendering, or a large JavaScript bundle that must execute before anything appears.
Images are the easiest win. Serving a 3000-pixel-wide photograph to a 400-pixel-wide phone screen is common and entirely avoidable with modern formats and correctly sized variants.
JavaScript is the harder one. If your page cannot render until a large bundle has downloaded and executed, LCP is bounded by that, and no amount of image optimisation fixes it.
CLS is the cheapest to fix
Layout shift is almost always caused by elements that arrive without reserved space: images without dimensions, fonts that swap and change text size, or banners injected above existing content.
The fixes are mundane — set explicit width and height on images, reserve space for anything that loads late, and avoid inserting elements above content that is already visible.
It is also the metric users notice most viscerally, because it makes them tap the wrong thing.
Measure with field data, not lab scores
A single Lighthouse run on your machine tells you very little. It reflects your device, your connection and one moment.
Search Console's Core Web Vitals report uses field data from real visitors on real devices. That is the number that matters, and it frequently disagrees with the lab score in an unflattering direction.
Use lab tools to diagnose and iterate quickly. Use field data to decide whether the problem is real.
A sense of proportion
Performance work has diminishing returns, and it is possible to spend months chasing scores that change nothing commercially.
Going from genuinely slow to reasonably fast is worth real money. Going from good to excellent is mostly worth pride. If your pages load quickly on a mid-range phone, the next hour is better spent on content than on shaving another hundred milliseconds.
The exception is if you are competing for a query where everyone's content is equally good. Then technical quality decides it, and the margins matter.
Want this built properly?
We build custom websites and the systems behind them with nothing to pay upfront, and are paid from the growth the work produces. We take a limited number at a time.