Technical SEO & Web Performance • Updated September 2026
A green Lighthouse score does not automatically mean your Core Web Vitals pass. Google evaluates LCP, INP and CLS using real-user field data, while Lighthouse is primarily a controlled lab diagnostic. Before compressing another image or removing JavaScript, identify which metric—and which part of that metric—is actually causing the poor experience.
By Rahul Saini, Founder / SEO Strategist at Search Counsel Co. Substantially updated September 2026.
What are Core Web Vitals?
Core Web Vitals are Google’s real-user experience metrics for loading, responsiveness and visual stability. A good result at the 75th percentile is LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less. Google uses Core Web Vitals in its ranking systems, but good scores do not guarantee high rankings. Use field data to judge the user experience and lab tools to diagnose what needs fixing.
The most important rule: diagnose before optimizing. Poor LCP does not automatically mean “compress the hero image.” Poor INP does not automatically mean “delete JavaScript.” First isolate the part of the metric that is slow, then fix the actual bottleneck.
Loading
LCP ≤ 2.5s
How quickly the main visible content appears.
Responsiveness
INP ≤ 200ms
How quickly the page responds visually after interactions.
Visual stability
CLS ≤ 0.1
How much unexpected layout movement users experience.
Jump to what you need
1. Core Web Vitals thresholds at a glance
Google evaluates Core Web Vitals at the 75th percentile. In practical terms, you want at least 75% of measured visits to fall within the “Good” threshold.
| Metric | Good | Needs improvement | Poor | Measures |
|---|---|---|---|---|
| LCP | ≤ 2.5s | > 2.5s to 4.0s | > 4.0s | Loading performance |
| INP | ≤ 200ms | > 200ms to 500ms | > 500ms | Interaction responsiveness |
| CLS | ≤ 0.1 | > 0.1 to 0.25 | > 0.25 | Visual stability |
INP replaced First Input Delay (FID) as the responsiveness Core Web Vital. If an older audit or article still treats FID as one of the current three Core Web Vitals, it is outdated.
2. Are Core Web Vitals a Google ranking factor?
Google confirms that Core Web Vitals are used by its ranking systems.
That does not mean:
- a page with perfect CWV automatically outranks a more relevant result;
- a Lighthouse score of 100 guarantees better rankings;
- Core Web Vitals are the only part of page experience Google considers;
- fixing CWV will recover every ranking loss.
Google’s current guidance is that strong Core Web Vitals can contribute to Search success and better user experience, but highly relevant content can still rank even when its page experience is weaker.
SEO takeaway: fix serious Core Web Vitals problems because they affect real users and are used by Google’s ranking systems. Do not sacrifice content quality, relevance or business functionality merely to chase a perfect performance score.
3. Which Core Web Vitals score should you trust?
This is where many audits go wrong.
Search Console, PageSpeed Insights, Lighthouse, Chrome DevTools and real-user monitoring can legitimately show different results because they are measuring different things.
The Core Web Vitals measurement decision matrix
| Source | Data type | Best use | Main limitation |
|---|---|---|---|
| Search Console CWV | CrUX field data grouped across similar URLs | Find sitewide/template problems | Not designed as an exact single-URL diagnostic |
| PageSpeed Insights field data | CrUX real-user data | Assess real-world URL/origin experience | Low-traffic URLs may lack URL-level data |
| Lighthouse | Synthetic lab test | Reproduce and debug performance | One controlled test is not your full real-user population |
| Chrome DevTools | Local diagnostic trace | Find exact tasks, resources and rendering bottlenecks | Represents the test environment |
| CrUX datasets/APIs | Public Chrome field data | Historical and programmatic monitoring | Privacy and sample thresholds apply |
| Your own RUM | Your site’s real-user measurements | Immediate monitoring, segmentation and regression detection | Requires implementation and enough representative users |
Simple rule: use field data to decide whether real users have a Core Web Vitals problem. Use lab and trace tools to understand why.
4. Lighthouse Performance score vs Core Web Vitals
A Lighthouse Performance score and a Core Web Vitals assessment are not the same measurement.
Lighthouse Performance score
Lighthouse runs a synthetic test under controlled conditions and combines multiple lab metrics into one weighted Performance score.
Core Web Vitals assessment
Core Web Vitals are LCP, INP and CLS measured from real-user experience when field data is available.
That means both of these situations are possible:
Lighthouse: 95+
Field CWV: Poor
Real users may encounter slow interactions, different devices, geographic latency or post-load shifts that your lab test did not reproduce.
Lighthouse: mediocre
Field CWV: Good
Your synthetic test may be harsher than the experience of the real users represented in CrUX.
Do not repeatedly rerun Lighthouse hoping the score will become your Search Console score. Use Lighthouse to reproduce and diagnose a problem.
5. Why Search Console and PageSpeed Insights can disagree
Two Google tools can show different Core Web Vitals results without either one being broken.
Common reasons include:
- URL grouping: Search Console reports similar URLs together.
- Exact URL vs origin data: PageSpeed Insights may not have enough field data for one URL.
- Mobile vs desktop: Search Console evaluates them separately.
- Field vs lab: the PSI page includes both types of information.
- Real-user mix: network, geography, hardware and browser conditions vary.
- Rolling field data: recent fixes do not instantly replace historical field observations.
- Post-load behavior: real visitors interact with pages in ways a simple lab page load may not reproduce.
If Search Console says Poor but your Lighthouse test is green:
do not assume Search Console is outdated or wrong. First check the failing metric, device type, URL group, PSI field data and whether your lab test can reproduce the real-user scenario.
6. How Search Console groups Core Web Vitals URLs
Search Console’s Core Web Vitals report is designed to identify problems affecting groups of similar pages—not to act as a precise lookup tool for every URL.
Google groups URLs that appear to provide a similar user experience. That often means pages sharing the same:
- template;
- framework;
- page type;
- layout;
- underlying performance bottleneck.
The LCP, INP and CLS status applies to the group for the relevant device category.
Search Console uses the group’s worst-performing Core Web Vital status to determine whether the group is Good, Needs improvement or Poor.
Why can one URL look better than its group?
Individual URLs can be outliers. A page can perform better or worse than other URLs grouped with it.
That is one reason the field result for a specific URL in PageSpeed Insights may not exactly match its Search Console URL group.
What is origin fallback?
Search Console must protect user privacy, so a URL group needs a minimum amount of real-user data before Google can show it.
If a lower-level URL group does not have enough information, Search Console can create a higher-level origin group containing data from URLs on the same protocol, host and port.
Practical consequence: the value you see may describe a broader group of experiences, not only the exact page you clicked.
7. What does “Not enough data” mean in Core Web Vitals?
It does not mean the page failed.
It means Google does not currently have enough qualifying Chrome real-user data to report the Core Web Vitals result with the required confidence and privacy protections.
This is common for:
- new websites;
- low-traffic pages;
- small niche sites;
- new templates;
- URLs with limited eligible Chrome telemetry.
What should you do?
Do not manufacture traffic just to produce a CrUX score.
Use:
- Lighthouse;
- Chrome DevTools;
- your own real-user monitoring where available;
- PageSpeed Insights field data at the origin level when relevant.
Then wait for enough natural field data to accumulate.
8. LCP: diagnose the four parts before optimizing the image
Largest Contentful Paint measures loading performance. The most useful way to optimize it is to stop treating LCP as one indivisible number.
Every LCP can be broken into four subparts:
| LCP subpart | What it measures | Common direction to investigate |
|---|---|---|
| TTFB | Time until the browser receives the first byte of HTML | Backend, caching, redirects, server/CDN latency |
| Resource load delay | Delay between TTFB and starting the LCP resource request | Late discovery, CSS/JS dependency, lazy loading, markup priority |
| Resource load duration | Time spent downloading the LCP resource | Image size, network path, compression, server/CDN delivery |
| Element render delay | Delay after the resource is available before the element is actually painted | Render-blocking work, client rendering, CSS, JavaScript, visibility logic |
Why this changes the fix
Imagine an LCP of 4.5 seconds where the image download itself takes only 400ms but element render delay consumes two seconds.
Compressing the image from 180KB to 120KB may improve the wrong part of the metric.
The bigger opportunity may be removing whatever prevents the already-loaded element from rendering.
Common LCP fixes—only when the diagnosis supports them
- Do not lazy-load the actual above-the-fold LCP image.
- Make critical LCP resources discoverable early.
- Use resource priority carefully where appropriate.
- Reduce unnecessary server latency.
- Optimize genuinely oversized images.
- Reduce render-blocking CSS/JavaScript where it delays the LCP element.
- Avoid making essential above-the-fold content depend unnecessarily on late client rendering.
For broader hosting, caching, CDN and image-delivery work, use our site speed optimization guide.
9. INP: diagnose input delay, processing and presentation separately
Interaction to Next Paint measures responsiveness across user interactions.
It is often discussed as a “JavaScript metric,” but that is incomplete.
An interaction contains three parts:
| INP phase | What is happening? | Typical investigation |
|---|---|---|
| Input delay | The user interacted, but the browser cannot start the handlers yet | Long main-thread tasks already in progress |
| Processing duration | The interaction’s callbacks are running | Expensive event handlers or synchronous JavaScript |
| Presentation delay | Handlers finished, but the browser still needs to render the next frame | Layout, style recalculation, rendering, painting, large DOM work |
If input delay dominates
Look for long tasks blocking the main thread before the interaction can begin.
If processing duration dominates
Inspect the event handler itself. Break up expensive synchronous work, defer work that does not need to happen before the next frame, and avoid doing unnecessary computation inside the interaction.
If presentation delay dominates
The event handler may not be the primary problem. Inspect rendering work, DOM size, style recalculation and layout/paint cost.
Better INP advice: “identify which interaction phase is slow” is more useful than “remove JavaScript.”
For deeper client-rendering and JavaScript architecture problems, continue with our JavaScript SEO guide.
10. CLS: find the element that actually shifts
Cumulative Layout Shift measures unexpected visual movement.
Common causes include:
- images without reserved dimensions;
- ads, iframes or embeds without reserved space;
- dynamically inserted banners or UI;
- late-loading content;
- web font metric differences;
- layout-changing animations.
Start by finding the shift
Use Chrome DevTools performance tooling to identify layout-shift events and which elements moved.
Then ask:
- Was space missing before an image loaded?
- Did an ad or embed expand?
- Was content injected above something already visible?
- Did the fallback font and final web font use significantly different metrics?
- Did an animation change layout instead of using a compositor-friendly approach?
Be careful with font advice
Simply adding font-display: swap does not guarantee zero layout shift.
A fallback font and web font can have different character metrics, causing text and surrounding elements to reflow when the font changes.
Depending on the design, useful options can include:
- a better-matched fallback font;
size-adjustand related font metric overrides;- preloading genuinely critical fonts;
- reducing unnecessary font files and variants;
font-display: optionalwhere the UX trade-off makes sense.
11. Which Core Web Vital should you fix first?
There is no universal rule that says:
“Always fix LCP before INP.”
Fix the bottleneck causing the largest real-user problem across the pages that matter.
Core Web Vitals diagnosis map
| What you see | First diagnosis | Do not automatically |
|---|---|---|
| Poor LCP | Break it into TTFB, load delay, load duration and render delay | Compress the hero image blindly |
| Poor INP | Split input, processing and presentation delay | Delete random JavaScript |
| Poor CLS | Identify the actual shifting element and cause | Change every image/font without evidence |
| Field bad, lab good | Investigate real devices, interactions, traffic segments and URL groups | Keep rerunning the same Lighthouse test |
| Lab bad, field good | Use the lab issue to prevent future regressions | Assume Google sees the site as failing CWV |
| Search Console has no data | Check CrUX availability and use lab/RUM evidence | Treat “no data” as a Poor result |
12. How to verify that a Core Web Vitals fix actually worked
A deployed fix and a confirmed field-data improvement are not the same event.
Use a layered validation workflow.
Step 1
Reproduce in lab
Confirm the code/resource/rendering problem is genuinely improved.
Step 2
Watch your RUM
See whether actual visitors start benefiting after deployment.
Step 3
Watch CrUX field data
Allow the rolling real-user dataset to incorporate new visits.
Step 4
Confirm in Search Console
Check whether the affected URL group improves after enough field evidence accumulates.
How long does a Core Web Vitals fix take to appear?
Lab tools can show the technical effect immediately after deployment.
Your own RUM can begin collecting improved user sessions immediately.
CrUX and Search Console are based on accumulated field experience, so they do not instantly replace historical observations the moment you deploy a fix.
Avoid making another major change simply because the Search Console graph has not turned green the next morning.
13. Advanced 2026 note: Core Web Vitals and SPA soft navigations
Single-page applications can change routes without a traditional full page load. Historically, this has made per-route Core Web Vitals measurement difficult.
In July 2026, version 6 of Google’s web-vitals library added support for measuring Core Web Vitals across supported soft navigations, and Chrome 151 began rolling out the underlying browser support.
For React, Next.js, Vue and similar SPA-style experiences, this makes it possible to collect more meaningful RUM measurements across client-side navigations.
Important limitation: Chrome’s current documentation says exactly how soft navigations will ultimately be represented in CrUX is still being determined. Do not assume that every client-side route is already evaluated in Search Console as if it were a conventional hard navigation.
This is primarily an advanced monitoring issue. Most sites should still start with the normal LCP, INP and CLS workflow above.
14. Core Web Vitals FAQ
What is a good Core Web Vitals score?
At the 75th percentile, Google recommends LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less.
Are Core Web Vitals a ranking factor?
Google confirms Core Web Vitals are used by its ranking systems. Good scores can contribute to Search success, but they do not guarantee top rankings and relevance remains critical.
Do I need a Lighthouse score of 100?
No. Lighthouse is a lab diagnostic and its overall Performance score is not the same as a Core Web Vitals field assessment. A perfect Lighthouse score is not an SEO requirement.
Why does Lighthouse pass while Search Console says Poor?
Lighthouse is a controlled synthetic test. Search Console uses accumulated Chrome real-user field data and groups similar URLs. Real devices, post-load interactions, device type, URL grouping and historical field observations can all create differences.
Is PageSpeed Insights the same as Search Console Core Web Vitals?
No. Both can use CrUX field data, but Search Console is designed around grouped sitewide issues while PageSpeed Insights focuses on the tested URL and may show broader origin data when specific URL data is unavailable.
What replaced FID?
Interaction to Next Paint (INP) replaced First Input Delay as the responsiveness Core Web Vital.
Why does Search Console say “Not enough data”?
Google does not have enough qualifying recent Chrome real-user data to report the group confidently. It does not mean the URL has failed Core Web Vitals.
What should I fix first: LCP, INP or CLS?
Fix the metric causing the most important real-user problem across your affected pages, then diagnose its underlying subpart. There is no universal rule that every website should always start with LCP.
Why is my LCP still poor after compressing the hero image?
Image download duration may not be the dominant part of your LCP. Check TTFB, resource load delay, resource load duration and element render delay separately.
Is INP always caused by JavaScript?
No. JavaScript is often important, but an interaction also includes presentation delay. Rendering, layout and painting can contribute significantly to poor responsiveness.
Can web fonts cause CLS?
Yes. A fallback font and final web font can use different metrics and cause text to reflow. Match fallback metrics, load critical fonts carefully and measure the actual layout shift before changing the font strategy.
How quickly will Google recognize a Core Web Vitals fix?
Lab tools can verify technical improvements immediately, while CrUX and Search Console require new real-user field data to accumulate. Expect field confirmation to lag behind deployment.
The one thing to do next
Do not start by optimizing everything. Open the real-user data, identify the failing metric and affected page group, reproduce the problem in a diagnostic tool, isolate the slow subpart, and fix that root cause first.
If the problem is broader site speed—hosting, caching, CDN delivery, image delivery or compression—continue with our site speed optimization guide.
If the bottleneck comes from client-side rendering, hydration or heavy JavaScript architecture, use our JavaScript SEO guide.
For the wider crawlability, indexation, rendering and technical-health framework, see our technical SEO guide.
If you need hands-on diagnosis across templates and real-user data, our technical SEO services page explains how we approach deeper technical audits.
Primary sources reviewed for this update
- Google Search Central — Understanding Core Web Vitals and Google Search results
- Google Search Central — Understanding page experience in Google Search results
- Google Search Console Help — Core Web Vitals report
- web.dev — Optimize Largest Contentful Paint
- web.dev — Optimize Interaction to Next Paint
- web.dev — Optimize Cumulative Layout Shift
- Chrome for Developers — Measuring soft navigations
- GoogleChrome web-vitals — version 6 soft-navigation measurement support
Editorial note: Core Web Vitals thresholds and Search Console reporting behavior are based on current Google and Chrome documentation. Lab scores, field measurements and third-party RUM tools can legitimately differ because they use different data sources, populations and measurement windows. Search Counsel Co. recommends diagnosing the real bottleneck rather than applying performance fixes solely because a generic checklist recommends them.