How to Improve Core Web Vitals, Metric by Metric

Most Core Web Vitals advice starts with a list of 30 tips. That's backwards.

You can't fix a metric until you know which one fails, on which template. Otherwise you'll compress images for a sprint while a chat widget blocks every tap.

Here's how to improve Core Web Vitals in six steps: find what fails, fix each metric at its root, then prove the fix held.

Core Web Vitals at a Glance

Core Web Vitals are three metrics Google uses to measure loading, responsiveness and visual stability.

Here are the thresholds, from web.dev's guides to each metric:

One detail changes how you read every report.

According to web.dev's Web Vitals overview, the threshold applies at the 75th percentile of page loads, segmented across mobile and desktop. In other words, three in four of your real visits need to hit "good".

INP replaced First Input Delay as the responsiveness metric. If an old report still mentions FID, it's out of date.

Before You Start: Trust Field Data Over Lab Scores

There are two kinds of performance data, and they answer different questions.

Field data comes from real Chrome users visiting your pages. It's what Search Console reports and what Google uses.

Lab data comes from a single simulated load in a tool like Lighthouse. It's useful for debugging, because you can repeat it.

When the two disagree, field data wins.

I've seen pages score in the 40s in a lab test while passing all three metrics for real visitors, and the reverse. Chase the lab score alone and you'll fix things nobody experiences.

You need three free tools:

• Search Console's Core Web Vitals report for which URL groups fail
• PageSpeed Insights for field and lab data on a single URL
• Chrome DevTools (the Performance panel) for finding the exact cause

Step 1: Find the Templates That Fail

Open the Core Web Vitals report in Search Console and start with mobile.

Google groups URLs that offer a similar experience, and gives each group the status of its slowest metric. So a group with good LCP and poor CLS shows as poor.

Click into each failing group and note:

• Which metric fails
• An example URL
• Roughly how many URLs share the problem

Then map each group to a template: product page, service page, blog post, location page.

This is the step most people skip. But it's the one that saves you time, because Core Web Vitals problems almost always live in templates. Fix the product template once and every product page improves.

Now prioritise. Put the templates that carry enquiries, bookings and checkout at the top. A failing blog archive can wait. If you're not sure which templates earn the most, the measurement section of my SEO audit checklist shows how to find out.

Note: Low-traffic sites often show "no data" because there isn't enough Chrome User Experience Report data. Use lab tests on your key templates instead, and treat them as a guide rather than a verdict.

Step 2: Diagnose Why Each Metric Fails

Take one example URL per failing template and run it through PageSpeed Insights.

Scroll past the score. The diagnostics below it tell you what to look at:

• For LCP, find which element is the LCP element. Is it a hero image, a heading or a background image?
• For INP, look for long main-thread tasks and heavy JavaScript.
• For CLS, find which elements shift and when.

Then confirm in DevTools.

Record a page load in the Performance panel with CPU throttling switched on, so your fast laptop behaves more like a mid-range phone. For INP, record while you tap the menu, open an accordion and submit a form.

Write down one sentence per template: "Product pages fail LCP because the hero image is loaded by a script." That sentence becomes your developer ticket.

Step 3: Speed Up Largest Contentful Paint

LCP is the time until the largest image, text block or video in the viewport renders.

web.dev's guide to optimising LCP breaks that time into four parts:

The two "delay" parts should be close to zero. Here's how to get them there.

Fix slow server responses first. web.dev warns that a high TTFB can make a 2.5-second LCP hard or impossible. Page caching, a better host and a CDN usually help most. Cut redirects on the way to the page, too.

Make the LCP image discoverable in the HTML. If the hero image only appears in a CSS file or a script, the browser finds it late. Put it in the HTML as an img element, or preload it.

Give it high priority. Add fetchpriority="high" to the one image most likely to be the LCP element. Not five images. web.dev notes that prioritising more than one or two makes the setting useless.

Never lazy-load the LCP image. It's the most common LCP mistake I find, usually caused by a plugin that lazy-loads every image on the page.

Shrink what blocks rendering. Keep CSS small, and load scripts with async or defer instead of synchronously in the head.

Serve the right image size. A 3,000-pixel hero squeezed into a phone screen is wasted download time. Use responsive images and a modern format.

Your platform changes which of these you control. I cover the specifics in my guides to speeding up WordPress, WooCommerce speed and Webflow site speed.

Step 4: Make Interactions Respond Faster (INP)

INP measures how quickly your page responds to clicks, taps and key presses across the whole visit. Hovering and scrolling don't count.

Every interaction has three phases, according to web.dev's guide to optimising INP:

1. Input delay: the wait before your code can start running, usually because the main thread is busy.
2. Processing duration: the time your event handlers take to finish.
3. Presentation delay: the time until the browser paints the next frame.

Fix whichever phase is longest.

Cut input delay by freeing the main thread. Long JavaScript tasks block everything. In my audits, the usual culprits are third-party tags: chat widgets, heatmaps, A/B testing tools and stacked marketing pixels. List every script, find its owner and remove what nobody uses.

Do less inside event handlers. web.dev's advice is to run only the work needed for the next visual update, then defer the rest. If a "filter" button recalculates the whole page before showing anything, split that work up.

Yield to the main thread. Breaking a long task into smaller ones lets the browser respond between them. Even crude yielding beats none.

Keep the DOM small. Huge pages make every update expensive. Mega menus with hundreds of hidden links and page-builder layouts nested ten levels deep are common offenders.

INP problems usually need a developer. Your job is to hand them a recorded interaction showing which phase is slow and which script owns it.

Step 5: Stop Layout Shifts (CLS)

CLS measures how much visible content moves without the user asking it to.

You know the feeling: you go to tap a button and an ad pushes it down.

web.dev's guide to optimising CLS names four common causes. Here's the fix for each:

Two more fixes catch the rest.

Animate with transforms. Moving elements with top or left shifts the layout. CSS transform doesn't.

Let pages use the back/forward cache. When a visitor returns with the back button, a cached page appears instantly, with no shifts at all.

Pro tip: Shifts within half a second of a tap or click don't count against you, because the user caused them. An accordion opening is fine. A banner sliding in on its own is not.

Step 6: Validate the Fix and Keep It Fixed

Once a fix ships, check lab data straight away to confirm it works.

Then go back to the Core Web Vitals report and click Validate Fix on the issue.

Search Console starts a 28-day monitoring session, because field data is a rolling window of real visits. Don't panic if the group stays red for the first fortnight.

Then protect what you've fixed.

Core Web Vitals regress quietly. A new marketing tag, a plugin update or a redesigned hero can undo months of work in one release. If a full rebuild is coming, add speed budgets to the brief; my guide on redesigning without losing SEO shows where they fit. I check field data for key templates monthly and run a lab test on staging before big releases.

For the wider set of technical checks to run alongside, see my technical SEO checklist.

Common Core Web Vitals Mistakes

These waste the most developer time in the projects I see:

• Chasing a 100 score. The goal is "good" at the 75th percentile, not a perfect lab number.
• Testing on desktop only. Mobile usually fails first, and Google indexes the mobile version.
• Fixing the homepage and stopping. Your product and service templates carry the revenue.
• Installing three speed plugins. They often conflict, and lazy-loading plugins regularly break LCP.
• Ignoring third-party scripts. They're often the biggest INP problem and the hardest to argue out, because someone in marketing owns each one. Check what each tag actually reports before you remove it; my Tag Manager best practices cover how to audit them.
• Judging a fix the next day. Field data takes up to 28 days to catch up.

Start With the Template That Earns the Most

Don't try to fix every URL group at once.

Pick the one template that brings in the most enquiries or sales, find which metric fails on it and ship one fix this sprint. Then validate it and move to the next.

Core Web Vitals are one layer of the wider technical picture. If you're unsure where speed sits among your other problems, my explainer on what technical SEO covers puts it in context.

Would you rather hand the diagnosis and developer tickets to someone else? Page speed on the templates that carry enquiries is part of my technical SEO support. I measure on a mid-range phone, start from field data and skip pages that earn nothing. You can see the rest of what a technical SEO engagement covers before you decide.