Core Web Vitals: what actually moves the number
Most Core Web Vitals work is four or five fixes repeated across the whole industry. Here is the order we work through them, and why lab scores keep misleading people.
Field data is the only data that counts
Google ranks on field data — real measurements from real Chrome users, reported through the Chrome User Experience Report. Lighthouse gives you a lab score from a single simulated load on one device profile.
The two disagree constantly, and when they do, the field data is what matters. A site can score 98 in Lighthouse and fail Core Web Vitals because actual users are on slower devices, worse networks and pages the lab test never visited. Start in Search Console, not in Lighthouse.
LCP is almost always an image or a font
Largest Contentful Paint is usually the hero image or the headline. If it is the image: it is probably not preloaded, probably not served in a modern format, probably sized for a desktop and sent to a phone, and possibly lazy-loaded when it should not be — lazy-loading your LCP element is a common own goal.
If it is the headline, it is the font. A web font that blocks rendering delays every word on the page. Preload the one font the first screen genuinely needs, serve it as WOFF2, use font-display: swap, and subset it to the characters you actually use.
INP is third-party JavaScript more often than yours
Interaction to Next Paint measures how long the page takes to respond. When it is bad, the cause is usually main-thread work blocking the response — and in most audits we run, the majority of that work belongs to scripts nobody on the team wrote.
Chat widgets, consent managers, tag managers loading six tags, session recorders, A/B testing tools that block rendering by design. Audit what is loading, ask what each one earns, defer everything that is not needed for the first interaction, and load the rest after the page is usable.
CLS is unsized elements, nearly every time
Cumulative Layout Shift comes from content arriving without reserved space. Images and videos without width and height attributes. Ads and embeds in containers with no dimensions. Banners injected above existing content. Fonts swapping between metrics that differ enough to reflow the text.
The fixes are mechanical: set dimensions or aspect ratios on every media element, reserve space for anything injected, and match your fallback font metrics to the web font so the swap does not move anything.
TTFB is the ceiling on everything else
Time to First Byte caps how good the rest can get. If the server takes a second to respond, no amount of front-end work produces a fast page.
For most sites the answer is caching — a CDN in front, full-page caching for anything not personalised, and a look at the database queries running on every request. Sites that are genuinely static should be served as static files from an edge network, at which point TTFB stops being a topic.
Measure, change one thing, measure again
The temptation is to apply every recommendation at once. Then the number moves and nobody knows which change did it, so the next site starts from guesswork again.
Field data takes twenty-eight days to fully reflect a change, which is frustrating but not negotiable. Make the change, note the date, and check back. Keeping a record of what actually moved the number on your own site is worth more than any general checklist, including this one.