A Core Web Vitals Checklist That Actually Moves the Needle

Core Web Vitals reporting is full of advice that technically helps and practically does nothing. Across our last twenty performance audits, eight fixes accounted for the overwhelming majority of the improvement. Here they are, in rough order of impact.

First, understand what you are measuring

• LCP (Largest Contentful Paint) — how long until the main content appears. Target under 2.5 seconds.
• CLS (Cumulative Layout Shift) — how much the page jumps around while loading. Target under 0.1.
• INP (Interaction to Next Paint) — how quickly the page responds when tapped. Target under 200ms.

Use field data from real users, not just lab scores. A Lighthouse run on a fast laptop tells you very little about a mid-range Android phone on a congested network, which is what most of your traffic actually is.

The eight fixes that mattered

1. Serve the LCP image in a modern format at the right size, and never lazy-load it. Lazy-loading the hero image is the single most common self-inflicted LCP wound we find.
2. Set explicit width and height on every image and reserve space for ad and embed slots. This alone usually fixes CLS outright.
3. Preconnect to font origins and use font-display: swap. Then subset the font — most sites ship weights they never use.
4. Move third-party scripts to defer or load them on interaction. Analytics, chat widgets and tag managers are usually the largest INP contributors.
5. Inline critical CSS for above-the-fold content and load the rest asynchronously.
6. Break up long JavaScript tasks. Anything over 50ms blocks the main thread and shows up directly in INP.
7. Enable compression and sensible cache headers at the CDN. Free, and frequently misconfigured.
8. Cut unused JavaScript. The median site ships two to three times what it executes.

What consistently did not help

Micro-optimising CSS selectors, obsessing over the exact Lighthouse number, and switching frameworks. We have seen teams spend a quarter on a rewrite that a properly sized hero image and three deferred scripts would have beaten in an afternoon.

Keep it from regressing

Performance is not a project. Without a budget enforced in CI, every site regresses within two release cycles.

Set a performance budget, enforce it in your pipeline, and fail the build when a bundle crosses the threshold. Pair that with real-user monitoring so you learn about regressions from your data rather than from a customer complaint.