Performance

Core Web Vitals Assessment Failed: How to Fix LCP, INP and CLS (2026 UK Guide)

By John Hitchens · Updated April 2026 · 12 minute read

If PageSpeed Insights is showing "Core Web Vitals assessment failed" for your site, something in your real-user field data is breaking Google's quality thresholds. It almost always comes down to one of three metrics: LCP, INP, or CLS. Fix the one that is red and your assessment passes. This guide shows you exactly how.

Core Web Vitals are three numbers Google uses to judge how good your website feels to real humans. If those three numbers are in the green, your site is fast, responsive, and stable, and Google rewards you with better rankings. If any of them are in the red, you are leaking rankings and conversions at the same time.

The three metrics are Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). Together they measure loading speed, interactivity, and visual stability. They replaced older metrics like First Input Delay in 2024, and they are now a confirmed ranking factor on both mobile and desktop.

This guide explains what each Core Web Vitals metric actually measures, what counts as a good score, how Google uses them in the algorithm, how to check your own scores for free, and the specific fixes for each metric when yours are in the red. It is written for non-technical UK business owners, so you do not need to understand JavaScript to follow it.

What Core Web Vitals are, in plain English

Imagine you click a link to a restaurant website because you want to book a table. You are waiting. How long did it take for the page to actually show you something useful? How quickly did the booking button respond when you tapped it? Did the page jump around while it was loading, making you tap the wrong thing?

Those three questions are, roughly, what Core Web Vitals measure.

• LCP answers: how long before the main content appeared?
• INP answers: how quickly did the page respond when I tapped?
• CLS answers: did the layout stay stable, or did things jump around?

Google calls them "Core" Web Vitals because they care enough about these three to make them ranking signals. There are other "web vitals" Google tracks, like Time to First Byte and First Contentful Paint, but they are not used directly for ranking. The three Core ones are.

The three Core Web Vitals metrics

1. Largest Contentful Paint (LCP)

LCP measures how long it takes for the largest visible element on the page to appear. Usually that is a hero image, a large block of text, or the main heading. The clock starts when the user clicks, and it stops when that biggest thing is fully painted onto the screen.

What counts as a good LCP:

• Good: under 2.5 seconds.
• Needs improvement: 2.5 to 4 seconds.
• Poor: over 4 seconds.

Why it matters: LCP is the user's first impression. If they see a blank white screen for 5 seconds, they are already reaching for the back button. Google's own data shows that pages with "good" LCP have noticeably higher engagement and lower bounce rates.

What causes poor LCP:

• A giant hero image that has not been compressed.
• Slow server response time (time to first byte over 600 ms).
• Render-blocking CSS or JavaScript at the top of the page.
• Web fonts that block text rendering.
• CDN not set up, so assets travel far from the server.
• Cheap shared hosting unable to serve pages quickly.

How to fix poor LCP:

1. Identify what the LCP element actually is. PageSpeed Insights tells you.
2. If it is an image, compress and resize it. Serve WebP or AVIF. Preload it using <link rel="preload">.
3. Move to better hosting if your server response time is over 600 ms.
4. Set up a CDN such as Cloudflare (free tier works).
5. Defer non-critical JavaScript.
6. Inline critical CSS, defer everything else.
7. Use font-display: swap so text appears immediately with a fallback font.

2. Interaction to Next Paint (INP)

INP measures how quickly your page responds when a user interacts with it. When someone taps, clicks, or presses a key, how long does it take before something visibly changes on screen? INP looks at every interaction during a visit and reports the slowest one (roughly).

INP replaced First Input Delay (FID) in March 2024. FID only measured the first interaction; INP measures all of them, which is a much better reflection of how the page actually feels to use.

What counts as a good INP:

• Good: under 200 milliseconds.
• Needs improvement: 200 to 500 milliseconds.
• Poor: over 500 milliseconds.

Why it matters: poor INP makes a site feel "stuck". You tap a button, and nothing happens for half a second. Users immediately tap again, causing double submissions and rage-clicks. Shopping carts and forms are especially vulnerable.

What causes poor INP:

• Heavy JavaScript handlers attached to clicks and taps.
• Long tasks on the main thread that block user input.
• Third-party scripts (chat widgets, tracking pixels, A/B test tools).
• Large frameworks like jQuery doing unnecessary work.
• Too many React re-renders on a single interaction.

How to fix poor INP:

1. Audit your third-party scripts. Remove any you are not actively using.
2. Defer non-critical JavaScript until after user interaction.
3. Break up long tasks into smaller chunks.
4. Use requestIdleCallback for non-urgent work.
5. On WordPress, install WP Rocket or a similar caching plugin with "delay JS" enabled.
6. Remove unused jQuery or lazy-load it.

3. Cumulative Layout Shift (CLS)

CLS measures how much the layout of your page jumps around while it is loading. Have you ever gone to tap a button, only for an image to suddenly pop in above it and push the button down, causing you to tap an advert instead? That is layout shift, and it is horrible.

CLS adds up every unexpected layout shift and gives you a single score. Low is good, high is bad.

What counts as a good CLS:

• Good: under 0.1.
• Needs improvement: 0.1 to 0.25.
• Poor: over 0.25.

Why it matters: CLS is the most infuriating problem for real users. Slow loading you can forgive. A site that keeps moving things around while you try to use it is something you just leave.

What causes poor CLS:

• Images without width and height attributes.
• Advertisements that load in and push content down.
• Web fonts that swap in and cause text to reflow.
• Dynamically injected content (popups, chat widgets, cookie banners) that do not reserve space.
• Lazy-loaded content that pops in without a placeholder.

How to fix poor CLS:

1. Add width and height attributes to every image. Modern browsers will reserve the correct space automatically.
2. Do the same for video and iframe embeds.
3. Reserve space for ad slots using CSS min-height.
4. Use font-display: optional or preload your fonts.
5. Make sure cookie banners are fixed position or pushed to the bottom, not injected at the top.
6. Use CSS transforms (translate) instead of top/left for animations.

What counts as a good Core Web Vitals score overall?

Google considers your page to be passing Core Web Vitals only if all three metrics are in the "good" range for at least 75 percent of real users. That last bit is important. Google does not use lab test data for ranking. It uses real-user field data from actual Chrome users, aggregated over 28 days, from the Chrome User Experience Report (CrUX).

That is why a site can score 98 in Lighthouse (lab) but still fail Core Web Vitals. Lab data is simulated on a fresh machine with a fast connection. Field data comes from real users on real phones on real 4G. Your real users are the ones Google listens to.

Here is the threshold summary:

• LCP: 75 percent of users experience under 2.5 seconds.
• INP: 75 percent of users experience under 200 ms.
• CLS: 75 percent of users experience under 0.1.

Hit all three and your page is considered "passing". Miss any one of them and your page is considered "failing" for that URL group.

How Google uses Core Web Vitals for ranking

Core Web Vitals are a confirmed ranking signal as part of Google's page experience update. They are not the biggest ranking signal. Content relevance, authority, and intent match still matter more. But when two pages are similar on content and authority, Google will prefer the one with better Core Web Vitals. In competitive UK niches, that tiebreaker is often the difference between position 3 and position 11.

Crucially, Google applies Core Web Vitals at the URL group level, not per page. If most of your pages fail, your whole site's rankings take a hit, not just the offending URLs. That is why a few slow pages can drag down the rest of your site.

Core Web Vitals also affect ad costs and eligibility. Google Ads uses landing page experience as a quality signal, and slow landing pages directly raise your cost per click.

How to check your Core Web Vitals for free

You have three main free sources of Core Web Vitals data:

PageSpeed Insights

Google's own tool. Shows both lab data (lighthouse) and field data (CrUX) for any URL. Start here. It is the source of truth.

Google Search Console

Under "Experience" then "Core Web Vitals", Search Console shows you which URLs on your site are failing which metric, grouped by URL pattern. This is the best place to see site-wide health.

PageScore

Our tool runs a quick synthetic audit and surfaces LCP and CLS-adjacent signals in the speed and mobile scores. Fast, no signup, and a good starting point when you just want an instant answer.

Run all three, compare the numbers, and prioritise whichever metric is worst.

Core Web Vitals vs Lighthouse vs PageSpeed Insights

These three terms get mixed up constantly. Here is the difference:

• Core Web Vitals is the name of the three metrics (LCP, INP, CLS).
• Lighthouse is the open-source tool Google uses to run lab tests on any URL. It produces a 0 to 100 performance score and measures Core Web Vitals in simulated conditions.
• PageSpeed Insights is Google's public website that runs Lighthouse in the cloud and also shows CrUX field data for your URL in one screen.

So when someone says "my Lighthouse score is 95", they mean the lab score. When someone says "I'm passing Core Web Vitals", they mean the field data thresholds. You want both to be good, but the field data is what actually affects ranking.

Common mistakes with Core Web Vitals

A few things people get wrong, from what I see in audits:

Obsessing over the lab score

A Lighthouse score of 100 means nothing if your real users are still getting 4 second LCPs on 4G. Always check the field data.

Testing only on desktop

Google ranks you on mobile Core Web Vitals. Mobile is almost always worse than desktop. Test on mobile.

Fixing the wrong metric first

If your LCP is 5 seconds and your CLS is 0.05, fix the LCP. Prioritise whichever metric is furthest from "good". Do not waste time polishing a metric that is already passing.

Forgetting about third-party scripts

A single badly-behaved third-party script can tank all three metrics at once. Audit yours. If a script does not directly make you money, it probably should not be running.

Thinking it is a one-off fix

Core Web Vitals drift over time as you add plugins, upload images, and embed new widgets. Monitor them monthly in Search Console.

Core Web Vitals checklist

Here is the one-page checklist I hand to clients after a Core Web Vitals audit:

LCP

• Server response time under 600 ms.
• CDN enabled.
• Largest image compressed, sized, and in WebP or AVIF.
• Largest image preloaded.
• Critical CSS inlined.
• Non-critical JavaScript deferred.
• Font-display: swap set on web fonts.

INP

• Third-party scripts audited and trimmed.
• JavaScript deferred or delayed until interaction.
• Long tasks broken up.
• No unnecessary jQuery.
• Click handlers lightweight.

CLS

• Every image has width and height attributes.
• Every iframe and video embed is sized.
• Ad slots reserve space.
• Cookie banner uses fixed position.
• Fonts preloaded or display: optional.
• No content injected above existing content after load.

Go through this list once, properly, and most sites pass Core Web Vitals within a week. Skipping it means you are leaving rankings on the table.