How to improve your Core Web Vitals

This guide is ordered the way I'd actually work through it. If you're new to the metrics themselves, start with Core Web Vitals, explained and come back.

Step 0: measure before you touch anything

Run the page through PageSpeed Insights. Look at the field data first (that's your real users), then the lab section to debug. Note which of the three is failing and on which device. Mobile is usually the harder one, and it's the one Google leans on most.

Write the starting numbers down. You can't tell whether a change helped if you didn't record where you began, and "it feels faster" is not a metric.

Improving LCP (loading)

LCP is the most fixable of the three. Work through these roughly in order of impact. Google's Optimize LCP guide goes deeper on each.

• Speed up the server response. A slow TTFB delays everything that follows. Cache HTML, put a CDN in front of your site, and check that your host isn't the bottleneck.
• Stop blocking the render. Render-blocking CSS and JavaScript hold up the first paint. Inline the small amount of CSS needed for the top of the page, defer or async the rest, and remove scripts you don't need. See render-blocking resources.
• Fix the LCP image. It's usually the hero. Compress it, serve a modern format (AVIF or WebP), size it for the device, and don't lazy-load it. Lazy-loading the hero image is one of the most common own-goals there is.
• Help the browser find it early. Add fetchpriority="high" to the LCP image, and preload it if it's discovered late (for example, a CSS background).
• Watch client-side rendering. If your above-the-fold content only appears after JavaScript runs, LCP waits for that JavaScript. Server-render or pre-render the important part.

Improving INP (responsiveness)

INP is about JavaScript getting out of the way so the page can respond. If INP is your problem, the cause is almost always too much script running on the main thread. The reference is Optimize INP.

• Ship less JavaScript. The cheapest long task is the one you never send. Audit your bundle, remove dead code, and split what's left so each page only loads what it needs.
• Break up long tasks. A single long task blocks every interaction behind it. Split heavy work into smaller chunks and yield to the main thread so the browser can respond between them.
• Tame third-party scripts. Tag managers, chat widgets, A/B testing tools, and ad scripts are the usual INP wreckers. Load them later, load fewer of them, and question whether each one earns its place.
• Move heavy computation off the main thread. Genuinely heavy work (parsing, sorting big lists) belongs in a web worker.
• Keep the DOM reasonable. A huge DOM makes every interaction more expensive. Use content-visibility for offscreen sections and don't render ten thousand rows at once.

Remember that lab tools can't measure INP, since nobody's clicking. They show Total Blocking Time as a proxy. To know your real INP, you need field data, which is exactly the kind of thing a one-off test won't give you.

Improving CLS (visual stability)

CLS is mostly about reserving space before content arrives. The patterns are well-documented in Optimize CLS.

• Give media dimensions. Set width and height (or a CSS aspect-ratio) on every image, video, and iframe, so the browser holds the space before the file loads.
• Reserve room for late content. Cookie banners, ads, and embeds that drop in at the top of the page shove everything down. Give them a fixed slot up front.
• Handle fonts carefully. A font swap can reflow your text. Preload key fonts and use font-display so the change is less jarring.
• Don't insert content above what people are reading. If you must add something dynamically, add it below the fold or in space you already reserved.

Don't forget mobile

It's worth saying twice: test mobile on its own. A page can be comfortably green on desktop and red on a mid-range phone, because phones have slower CPUs and flakier networks. Google assesses the two separately, and PerfHawk shows them side by side for the same reason. If you only ever check on your laptop, you're grading the easy exam.

Re-measure, then keep watching

After each change, re-run the page and compare against the numbers you wrote down in step 0. Real improvement shows up in the field data over the following weeks, because CrUX reports a 28-day rolling window of real visits, so be patient with field metrics.

Then comes the part most teams skip: keeping the wins. Performance backslides between releases. A new hero image, a third-party tag someone added for a campaign, a framework upgrade, and three weeks later you're back in the orange without a single alarm going off. Catching that needs a monitor that checks every day, not a reminder to test again "sometime."