Core Web Vitals: the three changes that move the numbers

We audit a lot of sites that have already had performance work done. Somebody spent a fortnight on it, the Lighthouse score improved, and the field data in Search Console barely moved.

That gap between lab and field is where most Core Web Vitals effort is wasted. In our audits, three changes account for the large majority of real improvement.

First, understand what you are measuring

Lab data — Lighthouse, PageSpeed Insights — is a simulated load on a simulated device on a simulated network. Useful for finding problems, useless as a target.

Field data — the Chrome User Experience Report, what Search Console shows, what real-user monitoring collects — is what actual visitors experienced on their actual devices. This is what Google uses, and it is the only number that matters.

A site can score 98 in Lighthouse and fail Core Web Vitals in the field, usually because real users are on slower devices, worse networks, or arriving at pages nobody tested.

Install real-user monitoring before you change anything. Without it you are optimising blind.

The three changes that move field data

1. Fix the largest contentful paint element specifically

LCP is the render time of the largest element in the viewport — usually a hero image, sometimes a heading, occasionally a video poster.

Most performance work reduces total page weight, which helps modestly. What actually moves LCP is making that one element arrive faster:

• Preload it. <link rel="preload" as="image" fetchpriority="high"> for the hero image, so the browser starts it immediately rather than after CSS parsing.
• Do not lazy-load it. Lazy-loading applied to every image, including the hero, is one of the most common self-inflicted LCP problems we find.
• Serve it in a modern format at the right size. AVIF or WebP, sized to the actual rendered dimensions, with responsive sources. A 2400px image displayed at 800px is three times the necessary bytes.
• If the LCP element is text, preload the font and use font-display: swap with a well-matched fallback.

On sites where the hero image was lazy-loaded and unprioritised, fixing that alone has taken LCP from around 4.5s to under 2s.

2. Reserve space for everything that loads late

Cumulative Layout Shift is caused by content arriving and pushing what is already rendered. Users experience it as tapping the wrong thing because the page moved.

The fixes are mechanical:

• Width and height on every image and video, so the browser reserves the box before the file arrives. Aspect-ratio boxes work equally well.
• Reserve space for ads and embeds with a fixed-height container, even if it is sometimes empty.
• Never inject banners above existing content — cookie notices, promotional bars, notification strips. Overlay them or reserve their space.
• Load fonts with a size-matched fallback. Use size-adjust and ascent-override so the fallback occupies the same space as the web font, eliminating the reflow when it swaps.

CLS is the easiest of the three to fix properly and the one most often left broken.

3. Cut main-thread work, particularly third-party scripts

Interaction to Next Paint measures responsiveness — the delay between a tap and something visibly happening. It is caused by the main thread being busy.

The single largest contributor on most business sites is third-party JavaScript. Tag managers, chat widgets, heat-map tools, A/B testing scripts, analytics, ad tags. Each is added by someone with a good reason, and nobody removes them.

• Audit what is actually loading. Open the network panel and list every third-party request. We routinely find scripts for tools the client stopped using two years ago.
• Defer everything non-essential until after interaction or after page load. Chat widgets in particular do not need to load before the page is usable.
• Break long tasks. Any script blocking the main thread for more than 50ms delays every interaction during that window.
• Question the A/B testing script. Synchronous testing tools that block rendering to avoid flicker are directly harmful to both LCP and INP.

What is usually not worth the effort

Chasing 100 in Lighthouse. The last ten points typically require disproportionate work and rarely register in field data.

Micro-optimising your framework bundle while three third-party scripts weigh five times as much as your application code. Fix the third parties first.

Server-side rendering everything on the assumption it must help. It helps LCP for content-heavy pages; it does nothing for CLS and can worsen INP if hydration is heavy.

Aggressive image compression that makes products look bad. For a commerce site, the conversion cost of ugly product images exceeds the SEO benefit of a slightly faster load.

A realistic sequence

1. Install real-user monitoring and wait two weeks for baseline field data.
2. Identify the specific LCP element on your three highest-traffic page templates.
3. Fix that element — preload, priority, format, size.
4. Audit third-party scripts and remove or defer everything non-essential.
5. Add dimensions to every image and reserve space for late-loading content.
6. Wait four weeks and check field data again.

That sequence typically takes a week of engineering and moves the numbers more than a month of general optimisation.

And the honest caveat

Core Web Vitals is a genuine ranking signal but a modest one. It is a tiebreaker between pages of comparable relevance, not a substitute for content that answers the query.

Fix performance because slow sites lose conversions and frustrate people. Treat the ranking benefit as a bonus rather than the objective, and you will make better decisions about where to stop.