Websites
Which Core Web Vital actually moves when you fix things
Cumulative layout shift is usually fixed in an afternoon by declaring image dimensions and reserving space for late content. Largest contentful paint responds to how the hero is delivered. Interaction latency is the one that needs architecture, not tuning.
Layout shift: cheap, and worth doing first
Nearly every shift comes from something arriving late without a reserved space — an image without width and height, a banner injected above content, a font swapping to different metrics. Declaring dimensions and reserving the space fixes most of it, and the fixes are individually small.
It is also the metric a visitor feels most directly. A page that jumps while someone is reaching for a link is not slow, it is unreliable.
Largest contentful paint: mostly about one element
Find the element the browser considers largest — usually the hero image or the headline — and ask what has to happen before it can paint. If the answer includes fetching a font from another host, running a script, or waiting for a request the browser did not know to start, that is the work.
The cheapest wins are ordinary: get the hero into the initial HTML, size it correctly, preload it, and self-host the font it sits next to.
Interaction latency: this one is architectural
How quickly a tap or a click registers is decided by how much JavaScript is competing for the main thread. You cannot tune your way out of a large bundle — you either ship less of it or you move the work off the critical path.
That is why static-first helps here more than anywhere else: the page is already interactive before the decoration arrives, so late work costs nothing that a visitor can feel.
Measure the pages people land on
Site-wide averages hide the problem. Check the templates that receive traffic — the homepage, the service pages, the one article that ranks — because those are where the metric is actually earned.
Article FAQs
Still have questions?The short answers.
Which should we fix first?
Layout shift, almost always. It has the clearest causes, the cheapest fixes and the most direct effect on how a page feels to use — a page that reflows under someone's thumb reads as broken regardless of how fast it loaded.
Do lab scores predict what real users get?
Not closely. A lab run uses one device profile on a throttled connection; field data covers everything your actual visitors use. Use lab runs to find causes and field data to decide whether you have a problem at all.
