Most speed advice is a list of tactics with no ordering, which is how teams end up minifying CSS on a site whose real problem is a 3MB hero image.
Core Web Vitals are useful precisely because they are not a general speed score. They measure three specific experiences a visitor actually has, and each one has a small number of realistic causes.
Fix the cause, not the score.
The Three Metrics
| Metric | Question it answers | Good | Poor |
|---|---|---|---|
| LCP | How long until the main content appears? | Under 2.5s | Over 4.0s |
| INP | How quickly does the page respond to input? | Under 200ms | Over 500ms |
| CLS | Does the layout jump while loading? | Under 0.1 | Over 0.25 |
You need to pass all three, at the 75th percentile of real visits. That last detail catches teams out: your fast laptop on office fibre is not the measurement. A mid-range Android phone on patchy 4G is much closer to it, and in India that is the majority of traffic.
Lab Data and Field Data Are Different Things
Before changing anything, know which number you are looking at.
Lab data comes from Lighthouse or PageSpeed Insights running a simulated load. Repeatable, immediate, useful for debugging. Not what Google ranks on.
Field data is the Chrome User Experience Report, collected from real Chrome users over 28 days. This is what Search Console shows and what counts.
The 28-day window is the practical consequence: a fix deployed today will not show in field data for weeks. Teams routinely ship a real improvement, check Search Console two days later, see nothing, and conclude it did not work. Use Lighthouse to verify the fix landed, then wait for the field data to catch up.
LCP: Time Until the Main Content Appears
LCP marks when the largest element in the viewport finishes rendering. Usually a hero image, a heading, or a video poster.
Find the element first
PageSpeed Insights names it. So does Chrome DevTools under Performance. Do not guess, because the fix depends entirely on what the element is.
If it is an image, which it usually is
Serve the right format. WebP or AVIF instead of JPEG or PNG. Typical saving is 30 to 50 percent at the same visual quality, and this is often the single largest win available.
Serve the right size. A 4000px wide image displayed at 800px wastes the difference. Use responsive sizes so a phone downloads a phone-sized file.
Preload it. The browser cannot discover an image referenced in CSS until it has parsed the CSS. A preload hint in the head starts the download immediately.
Never lazy-load it. Lazy loading below-the-fold images is correct. Lazy loading the hero image delays the exact element LCP measures. This mistake is common because a plugin applied lazy loading to everything.
If it is text
The cause is almost always a web font. The browser has the text but will not paint it until the font arrives.
Use font-display: swap so text renders immediately in a fallback and swaps when the font loads.
Self-host fonts instead of pulling from a third-party origin. That removes a DNS lookup and a TLS handshake from the critical path.
Preload the font files you use above the fold, and only those.
Server response
If your server takes 800ms to send the first byte, nothing downstream can rescue LCP. Check Time to First Byte. On a static site it should be under 200ms; above 600ms points at hosting, a missing cache, or slow database work on the critical path.
INP: How Fast the Page Responds
INP replaced First Input Delay because FID only measured the first interaction and only its delay, not how long the response took. INP measures every interaction and reports near the worst.
INP is almost always a JavaScript problem. The main thread is busy, so it cannot respond to a tap.
Cut JavaScript you do not need. The most effective fix and the least popular one. Audit the bundle. Analytics, chat widgets, A/B testing tools, and social embeds compound quickly, and each one is somebody's favourite.
Break up long tasks. Any task over 50ms blocks input. Split work and yield to the main thread between chunks.
Defer everything non-critical. Third-party scripts should load after the page is interactive, not before. Chat widgets in particular do not need to load in the first second.
Watch for expensive event handlers. A scroll or input handler doing layout work on every event is a classic cause. Debounce, and read layout properties outside the handler where you can.
Avoid layout thrashing. Reading a layout property such as offsetHeight after writing a style forces the browser to recalculate synchronously. In a loop, this is quadratic.
CLS: Whether the Layout Jumps
CLS is the most annoying to experience and the easiest to fix. It has four causes and that is essentially the whole list.
Images without dimensions. The browser does not know how much space to reserve, so text renders, then the image arrives and shoves everything down. Set width and height attributes, or an aspect ratio in CSS. This one fix resolves most CLS problems.
Ads, embeds, and iframes. Same problem, injected later. Reserve the space with a fixed-size container.
Content injected above existing content. Cookie banners, promotional bars, and notification strips that push the page down after it has rendered. Overlay them, or reserve their height from the start.
Web fonts. A fallback font with different metrics reflows the text when the real font swaps in. size-adjust and the ascent-override descriptors let you match the fallback's metrics closely enough that the swap is invisible.
Fix in This Order
- Optimise the LCP image. Format, dimensions, preload, no lazy loading. Frequently the largest single improvement on the whole site.
- Set dimensions on every image. Usually clears CLS on its own.
- Audit third-party scripts. Remove what nobody uses, defer the rest. Helps INP and LCP together.
- Fix fonts. Self-host,
font-display: swap, preload the critical ones. - Then look at code splitting and the rest.
Steps one and two are an afternoon and cover most sites. Everything below step three is diminishing returns until they are done.
What This Is Actually Worth
Core Web Vitals are a ranking factor, but a modest one. Google has been clear that better content beats a faster page.
The reason to do this work is conversion, and the effect there is not modest. Bounce rate climbs steeply between one and three seconds of load time. On mobile, on a mid-range Android over 4G, which describes most of the Indian market, a heavy page does not lose a ranking position, it loses the visit entirely.
Treat it as a revenue problem that happens to also be an SEO one.
Measure It Properly
- Search Console, Core Web Vitals report. Field data, grouped by URL pattern. Start here.
- PageSpeed Insights. Field and lab side by side for a single URL.
- Chrome DevTools, Performance panel. Where you find the actual cause.
- Throttle to a mid-tier mobile on slow 4G. Test what your users have, not what you have.
Where This Sits
Speed is one part of technical health. Crawlability, indexation, canonicals, and structured data are the rest, and we cover them in the technical SEO audit. If the underlying build is the problem rather than the tuning, choosing the right tech stack is the earlier conversation.
Site Failing Its Vitals?
Our software team rebuilds and tunes sites for performance, and the fix is usually smaller and less dramatic than people fear.