Core Web Vitals in 2026: what to fix first when LCP, INP, or CLS fails
Direct answer
If a page is near page one but gets weak engagement, Core Web Vitals are worth checking, but they are not a ranking diagnosis by themselves.
Start with three questions:
- Is the problem visible in field data, not just one test run?
- Which metric is actually failing: LCP, INP, or CLS?
- Is the issue really page experience, or is it a different problem such as rendering, indexing, or intent mismatch?
Google’s current Search guidance for Core Web Vitals and page experience makes the boundaries clear: good scores help page experience, but they do not guarantee rankings.
The current metrics and thresholds
The current three metrics are:
- Largest Contentful Paint (LCP) for loading performance. See web.dev’s LCP guide.
- Interaction to Next Paint (INP) for responsiveness. See web.dev’s INP guide.
- Cumulative Layout Shift (CLS) for visual stability. See web.dev’s CLS guide.
Google recommends evaluating the 75th percentile of visits:
| Metric | Good | Needs improvement | Poor |
|---|---|---|---|
| LCP | ≤ 2.5 s | > 2.5 s and ≤ 4.0 s | > 4.0 s |
| INP | ≤ 200 ms | > 200 ms and ≤ 500 ms | > 500 ms |
| CLS | ≤ 0.1 | > 0.1 and ≤ 0.25 | > 0.25 |
One real change you should account for is that INP replaced FID in Google’s current Core Web Vitals set. If a 2023 or early-2024 checklist still treats FID as current, it is outdated.
Start with field data, not one Lighthouse score
When teams say “our Core Web Vitals are bad,” they often mix three different evidence sources:
| Source | What it is good for | What it cannot prove |
|---|---|---|
| Search Console Core Web Vitals report | Spotting affected URL groups from 28-day field data | The exact bottleneck on one page today |
| CrUX / PageSpeed Insights field data | Checking whether real users actually experience a problem | The exact code change to make |
| Lighthouse lab runs | Reproducing and debugging likely causes | Your current ranking state or 28-day field status |
Google’s Search Console Core Web Vitals report documentation is especially important here: the report is based on field data and URL groups, not a one-time crawl of one page.
A reproducible lab example
On July 26, 2026, I ran a Lighthouse performance test against https://fennecseo.app/ with:
npx --yes lighthouse https://fennecseo.app/ \
--only-categories=performance \
--output=json \
--output-path=./lighthouse.json \
--quiet \
--chrome-flags="--headless=new --no-sandbox"
The sample output was:
URL: https://fennecseo.app/
Fetch time: 2026-07-26T09:50:55.929Z
Performance score: 46
FCP: 4.0 s
LCP: 4.0 s
Speed Index: 8.8 s
TBT: 1,390 ms
CLS: 0.014
That output is useful because it tells us this page likely has load and main-thread work issues before we even debate rankings. It is also limited:
- it is lab data, not CrUX field data;
- it reports TBT, which is a lab diagnostic proxy, not field INP;
- it does not prove that rankings dropped because of Core Web Vitals.
Use this kind of sample to locate likely causes, then confirm the user-facing impact with field data.
What to fix first by metric
If LCP is failing
Start by identifying the actual LCP element. Then work through these likely causes:
- slow server response or redirect delay;
- late discovery of the hero image or text block;
- render-blocking CSS or JavaScript;
- lazy-loading the above-the-fold hero asset;
- client-side rendering that delays the main content.
The fastest wins are often HTML caching, removing unnecessary redirects, preloading the real hero asset, and reducing blocking work before the LCP element can render.
If INP is failing
Treat INP as an interaction problem, not a page-load-only problem.
Check for:
- long main-thread tasks after the page becomes visible;
- oversized JavaScript bundles;
- expensive click, input, or filter handlers;
- third-party scripts that delay interaction;
- large rerenders after one user action.
If field INP is poor but Lighthouse load metrics look acceptable, the bottleneck is often in interaction handlers rather than raw loading.
If CLS is failing
Look for the moving element, not just the final score.
Common causes include:
- images or embeds with no reserved dimensions;
- banners, consent bars, or notifications injected above existing content;
- fonts swapping late and moving headings;
- client-side components that expand after initial paint.
CLS work is usually layout discipline, not “make the page faster” in a generic sense.
When it is not really a Core Web Vitals problem
Do not use CWV as a catch-all explanation.
Sometimes the real issue is:
- the title and opening answer do not match the query;
- important content appears only after JavaScript rendering;
- canonical, hreflang, or indexing controls are wrong;
- the page loads, but the main task is still hard to complete.
If the content is missing from rendered HTML, check Googlebot WRS and JavaScript SEO before you blame CWV. If the page is indexable but weak for its query, use the SEO Audit tool and your own Search Console evidence to separate UX from intent problems.
What Core Web Vitals can and cannot say about SEO
Google’s page experience guidance says its ranking systems use page experience signals and want to reward pages with a good user experience. The same guidance also says that great page content can still rank well even if page experience is subpar.
That means:
- better CWV can reduce friction for real users;
- poor CWV can be a valid diagnosis target;
- good CWV does not guarantee higher rankings;
- bad CWV does not prove that relevance, content quality, or rendering are fine.
This is why “we improved Lighthouse from 46 to 80, so rankings should rise” is not a reliable conclusion.
A practical verification workflow
- Check the Search Console Core Web Vitals report for the affected URL group and device class.
- Open PageSpeed Insights for the representative URL and separate field data from lab data.
- Run a reproducible Lighthouse test and save the JSON output.
- Fix the measured bottleneck for the failing metric, not a generic checklist item.
- Re-test for regressions in layout, rendering, and conversion paths.
- Annotate the release date and wait for enough field data before judging the result.
Common mistakes
- Treating one Lighthouse score as proof of a field-data problem.
- Optimizing TBT and claiming INP is fixed without checking field evidence.
- Saying “Core Web Vitals are the reason rankings dropped” without ruling out indexing, rendering, and content-intent issues.
- Improving lab speed while leaving the actual LCP element unchanged.
- Celebrating a green CLS score while the page still feels hard to use.
What to do next
- Use the Core Web Vitals checker for a quick page-level check.
- Read the tighter definition page at Core Web Vitals Wiki.
- If the issue may be broader than speed, run the SEO Audit tool.
- If content appears only after client-side rendering, continue with Googlebot WRS and JavaScript SEO.
Q&A
What are the current Core Web Vitals thresholds?
At the 75th percentile of visits, aim for LCP at or below 2.5 seconds, INP at or below 200 milliseconds, and CLS at or below 0.1.
Can one Lighthouse run prove a Core Web Vitals problem?
No. A Lighthouse run is lab data. It is useful for reproducing and debugging issues, but it does not replace 28-day field data from CrUX or Search Console.
Do better Core Web Vitals guarantee better Google rankings?
No. Google uses page experience signals, but relevance and helpful content still matter more than a good CWV score alone.
