Both are right, because they measure different things. This article explains what the assessment is, what each of the three metrics means, why sites usually fail them, and what to fix first so you aren't paying someone to chase a score.
What the Core Web Vitals assessment actually measures
The assessment at the top of PageSpeed Insights isn't a test of your site. It's a report on your visitors.
It comes from the Chrome User Experience Report, which collects timings from real people using Chrome who have agreed to share usage statistics. Google looks at the last 28 days of visits and takes the 75th percentile for each metric. In plain terms: three out of four visits have to meet the target for that metric to pass. One quick visit on fast office wi-fi doesn't count for much; a lot of slow visits on phones in a car park do.
To pass, all three metrics must be good at that 75th percentile. Fail any one, and the whole assessment fails.
That's why it can disagree with the score further down the page. The performance score comes from Lighthouse, which loads the page once on a simulated mid-range phone with a throttled connection. That's lab data: useful for testing a fix, repeatable, but not what your visitors experienced. The assessment is field data. Google's Search Console Core Web Vitals report uses the same field data, grouped by similar pages, so that's the one to watch.
If your site doesn't get enough Chrome traffic, PageSpeed Insights may show the result for your whole domain instead of that page, or no field data at all. Then Lighthouse is all you've got, and you should treat it as a guide, not a verdict.
The three metrics and their targets
Google publishes the thresholds at web.dev:
- Largest contentful paint (LCP): how long until the biggest thing on the first screen, usually a hero image or headline, has appeared. Good is 2.5 seconds or less.
- Interaction to next paint (INP): how quickly the page visibly responds when someone taps, clicks or types. Good is 200 milliseconds or less.
- Cumulative layout shift (CLS): how much the content jumps around while the page loads. Good is 0.1 or less.
Lighthouse can't measure INP, because nobody taps anything during a lab test. It reports total blocking time instead, which is a reasonable warning sign for the same problem.
Why sites fail each one
Slow website loading is rarely down to one thing. But each metric has its usual suspects, and the field data tells you which one to start with.
Failing largest contentful paint
This is the most common failure, and the causes tend to stack up:
- A slow server response. If the server takes a second to start sending the page, everything else starts a second late. No caching, an overloaded shared host or a page that's rebuilt from the database for every visitor all show up here.
- An oversized hero image. A 3 MB photo sent to a phone that displays it 400 pixels wide.
- The hero image found too late. If it's set as a CSS background, injected by a slider script or marked to lazy-load, the browser doesn't start downloading it until well after the page arrives.
- Render-blocking files. Stylesheets and scripts in the head that must download before anything paints.
- Web fonts. If the largest element is a headline, the browser may wait for the font before it shows the text.
Failing interaction to next paint
INP is about JavaScript. When the browser is busy running scripts, it can't respond to a tap, so the menu opens late or the button seems dead.
- Third-party scripts: chat widgets, heatmaps, ad pixels, social embeds and tags in Google Tag Manager that nobody remembers adding.
- Page builders and heavy themes that ship a lot of JavaScript to every page, used or not.
- Large pages: thousands of elements make every update slower for the browser.
Failing cumulative layout shift
- Images and embeds without dimensions, so the browser doesn't reserve space for them and the text below jumps when they load.
- Banners that push content down: cookie notices, promotions and announcement bars inserted at the top after the page has drawn.
- Fonts swapping in at a different size from the fallback font.
- Ads and embeds that resize themselves once they've loaded.
What to fix first
Here's the order I'd work in, and it's a structural one, not a list of tricks.
1. Find which metric is failing, on which pages, on which device. Open the Core Web Vitals report in Search Console. It splits mobile from desktop and groups similar URLs. Mobile usually fails first, so start there.
2. Start with the template that carries the most traffic. Pages built from the same template usually share the same problem. Fixing the product template or the service page template fixes hundreds of URLs at once. Fixing one blog post fixes one blog post.
3. Fix the failing metric's biggest cause, then re-test. For LCP, that usually means server response and caching first, then the hero image, then render-blocking files and fonts. For INP, list every third-party script and remove what nobody uses before optimising what's left. For CLS, give every image and embed its dimensions and stop banners pushing content down.
4. Test each fix in the lab before you wait on the field data. Lighthouse and the performance panel in Chrome's developer tools tell you within minutes whether a change helped. The field data takes weeks.
5. Stop it creeping back. New plugins, new campaign tags and full-size image uploads are how fast sites become slow ones again. Someone needs to own that.
What not to do first: install a speed plugin and hope, or redesign the site. A plugin can help with caching and images, but it can't remove a chat widget your sales team relies on, and it sometimes breaks things it tries to combine. A rebuild might be the right answer, but only once you've shown the current platform can't be fixed.
A worked example: this website
On 6 October 2026 I worked on the homepage of this site, anthonykeal.com.au. It was already in good shape: a Lighthouse mobile performance score of 94, with a largest contentful paint of 2.9 seconds in the lab test. That's above Google's 2.5 second target, so it was worth a look.
Two changes did most of it:
- The hero photo. On phones, my photo sits below the first screen, but the page was still asking for it early and at a size larger than a phone needs. It now has smaller versions for phones and loads lazily, so it no longer competes with the headline.
- The stylesheet. Inlined into the page instead of loaded as a separate file, so the first paint doesn't wait on another request.
The result, in Lighthouse: mobile performance 99 to 100 depending on the run, largest contentful paint 1.5 to 2.0 seconds, and desktop 100.
Two lessons in that. First, lazy loading is only right for images that aren't the largest paint. Lazy-loading your hero image when it is the largest thing on the first screen is one of the most common ways to fail LCP; here it worked because on phones the photo isn't. Second, these are lab figures. They show the fixes worked on a simulated phone. Whether real visitors see the same improvement is what the field data answers, and that takes time.
How long until Search Console updates?
Because the field data covers a rolling 28 days, a fix you make today is diluted by three and a half weeks of slower visits. Expect the numbers to move gradually over about a month, not overnight.
In Search Console's Core Web Vitals report, once you've fixed an issue, click "Validate fix". Google then monitors the affected pages over a 28-day period and marks the issue passed or failed at the end. If your site has low traffic, it can take longer, because there's less data to work with.
So: test in the lab to know a fix worked, then use the 28 days to fix the next thing rather than refreshing the report.
Running a Core Web Vitals test yourself
You don't need a consultant to see where you stand:
- Put your homepage and your most visited service or product page into PageSpeed Insights. Read the field data at the top first, mobile tab first.
- Open the Core Web Vitals report in Google Search Console to see which groups of pages fail, and on which metric.
- Expand the Lighthouse diagnostics below the score. "Largest Contentful Paint element" tells you exactly what the LCP is waiting on.
If the cause is obvious, such as a huge image or a forgotten script, you or your developer can probably fix it this week.
When to get help
Get help when the fixes aren't obvious, when they need changes to the theme, hosting or tag setup that nobody on your team owns, or when you've already tried a speed plugin and the assessment still fails.
I do this as website speed optimisation: I measure your real pages, fix the causes in order of impact on the platform you already have, and give you before and after figures. If speed is one symptom among several, such as dropping enquiries, analytics nobody trusts or pages that won't rank, start with a Website Health Check, which covers speed and Core Web Vitals alongside six other areas and ranks every fix.
