Share this post:
Run a Lighthouse audit on almost any website and the owner will assume they’ve checked their Core Web Vitals. Lighthouse is a simulation on a controlled device, whereas Core Web Vitals are measured from real Chrome users on real connections. Google formalised these metrics in 2021 as part of its Page Experience ranking signals: three measurements of how a page performs for the person using it. Getting all three into the Good band earns a ranking signal, but miss one and the others count for nothing.
What Are Core Web Vitals?
Core Web Vitals are three performance metrics Google uses to score real user experience: how fast the main content loads, how quickly the page responds to input, and whether the layout stays stable. Google announced them in May 2020 and officially tied them to rankings through the Page Experience update in mid-2021.
Scores come from opted-in Chrome users through the Chrome User Experience Report (CrUX) over a rolling 28-day window, meaning each score reflects a genuine average across real sessions, not a single test. To achieve Good status, a page must pass all three thresholds simultaneously at the 75th percentile of those visits, with no partial credit. The 2025 Web Almanac reports mobile pass rates at 48% and desktop at 56%.
The Three Core Web Vitals: LCP, INP, and CLS
Google chose these three metrics because each one captures a distinct type of user frustration: waiting for content, being ignored on a tap, and watching text jump mid-read. Worth noting before the metric breakdowns: INP replaced First Input Delay in March 2024. FID only measured the delay before the first response began, while INP measures the full response time across every interaction in a session, a considerably stricter standard.
Largest Contentful Paint (LCP): Loading
LCP tracks how long the single largest visible element in the viewport takes to fully render, typically a hero image, a heading, or a video thumbnail. Under 2.5 seconds is Good, 2.5 to 4 seconds Needs Improvement, and beyond 4 seconds is Poor. Per the 2025 Web Almanac, only 62% of mobile pages pass LCP, making it the hardest threshold to clear
Unoptimised images cause most failures: oversized files, outdated JPEG formats where WebP or AVIF would load significantly faster, and lazy-loading applied to the LCP element itself, which instructs the browser to defer the exact asset Google is measuring. Adding fetchpriority=”high” to the LCP element and converting to a modern format addresses the image side directly. If the image loads via CSS or JavaScript rather than a standard <img> tag, a <link rel=”preload”> in the document head is also needed. Slow server response time (TTFB) and render-blocking JavaScript or CSS compound the problem by delaying when any content can paint.
Interaction to Next Paint (INP): Responsiveness
INP measures the gap between a user action, such as a click, tap, or key press, and the moment the browser visually confirms something happened. Unlike FID, which only captured the first interaction, INP logs every interaction in a session and scores the slowest one, excluding the top 5% of outliers, so a page that bogs down mid-session during a form submission will still fail regardless of how fast it loads.
The Good threshold is under 200ms, with 200ms to 500ms needing work and anything beyond 500ms considered poor. INP has the highest pass rate of the three at 77% of mobile pages, but failures are harder to diagnose because they don’t appear in standard load-time tests. The cause is almost always main thread congestion: third-party analytics scripts, ad libraries, or chat widgets running expensive synchronous tasks that block the browser from responding to interactions. React hydration is a frequent contributor, leaving pages visually complete but functionally unresponsive until JavaScript finishes wiring up event handlers.
Cumulative Layout Shift (CLS): Visual Stability
CLS measures how much the page layout unexpectedly moves during and after loading as late-loading images, ads, and fonts displace existing content. Unlike LCP and INP, CLS accumulates across the full session, so an ad loading five seconds in still adds to the score.
Good is below 0.1, Needs Improvement is 0.1 to 0.25, and Poor is above 0.25. Eighty-one percent of mobile pages pass, making it the most achievable of the three, though layout shift remains highly visible when it does occur. The leading cause is images and video elements without declared width and height attributes, because the browser cannot reserve space before they load. Ads inserted above existing content, web fonts causing text to reflow, and embeds rendering at unexpected sizes all contribute. Declaring explicit dimensions on every media element is the single highest-impact fix, resolving the most common source of layout instability with one HTML attribute change.
Core Web Vitals as an SEO Ranking Factor: What Google Actually Says
Google has confirmed Core Web Vitals as a ranking factor, but also confirmed they act as a tiebreaker between pages with comparable content quality rather than a primary signal overriding relevance. The documented position: “In general, we prioritise pages with the best information overall even if some aspects of page experience are sub-par.”
A technically fast page won’t outrank a genuinely authoritative one purely on performance. CWV creates a competitive advantage in tight SERPs, particularly in mobile-heavy verticals where mobile-first indexing makes mobile performance the primary scoring input, and on transactional pages where load stability directly influences conversion. Critically, passing two thresholds while failing the third yields zero CWV ranking benefit. All three must pass simultaneously at the 75th percentile. Only real-user field data from Chrome affects rankings; Lighthouse and PageSpeed Insights lab scores are diagnostic, not ranking inputs.
Lab Data vs. Field Data: Why Your Lighthouse Score Is Not Your Core Web Vitals
Field data, what Google uses for rankings, comes from real Chrome users through CrUX over a 28-day window. Lab data, what Lighthouse produces, simulates a single page load on a controlled device and network. A page scoring 95 in Lighthouse can still fail LCP in field data because the lab doesn’t run third-party scripts, doesn’t account for mobile users on variable connections, and captures only one idealised visit.
Use Lighthouse to diagnose what to fix, and Search Console or PageSpeed Insights field data to confirm whether it worked. CrUX updates on a 28-day rolling cycle, so changes deployed today won’t appear in Search Console for up to four weeks. That lag prevents a single good day from masking poor overall performance, but it also means expecting visible movement within a week of a deployment will always lead to a false reading.
How to Measure Core Web Vitals: The Right Tools for the Right Data
Four tools cover CWV measurement, each answering a different question, and using the wrong one for the wrong question produces misleading conclusions.
Google Search Console (Field Data, Site-Wide)
Google Search Console is the right starting point. Its Core Web Vitals report groups URLs by status (Good, Needs Improvement, Poor) for mobile and desktop separately, using real CrUX data. The limitation worth knowing: Search Console groups URLs rather than showing individual pages, so a small number of high-traffic pages failing badly can pull an otherwise healthy site into Needs Improvement status without the grouping making the source obvious. Use it to identify where failures cluster, then move to PageSpeed Insights for page-level investigation.
PageSpeed Insights (Field Data and Lab Data, Per URL)
PageSpeed Insights shows CrUX field data for a specific URL at the top of its report and Lighthouse lab data below. For ranking purposes, only the field data section at the top reflects what Google sees. Use PSI after Search Console has identified a failing URL group, entering the specific page to see its real CWV status and the Lighthouse opportunities that explain what to address first.
Chrome DevTools and Lighthouse (Lab Data, Diagnosis)
Lighthouse runs inside Chrome DevTools under the Lighthouse tab or through PageSpeed Insights. It scores a single simulated page load against performance, accessibility, SEO, and best practices, with specific recommendations attached to each finding. The correct use is pre-deployment, catching performance regressions before real users encounter them. A passing Lighthouse score does not confirm CWV will pass in field data; confirming that requires checking CrUX field data after the full 28-day window has elapsed.
CrUX for Raw Field Data
CrUX is the dataset Google builds from opted-in Chrome visits across hundreds of millions of URLs, updated monthly. Most practitioners reach it through Search Console and PageSpeed Insights, though direct access is available via the CrUX API or the CrUX Dashboard in Looker Studio. Pages with insufficient Chrome traffic won’t generate individual field data, causing Google to fall back to origin-level data from comparable pages on the same site, which is why getting high-traffic pages into the Good range first builds the baseline that lower-traffic pages inherit.
Common Core Web Vitals Failures and How to Fix Them
Performance failures rarely have a single cause. An e-commerce audit found a 15-second LCP traced to seven interacting issues across different teams. Understanding what drives each metric is what makes it possible to isolate and fix the right problem, which is the core of any technical SEO audit.
LCP Failures: Image and Server Issues
LCP failures typically come from four sources acting together. The LCP image itself is the most common: wrong format (JPEG instead of WebP or AVIF), a file that is too large, or lazy-loading applied directly to the LCP element, which tells the browser to defer loading the asset Google is scoring. Adding fetchpriority=”high” and converting to WebP or AVIF resolves the image-side issues directly. If the image loads via CSS or JavaScript rather than a standard <img> tag, a <link rel=”preload”> in the document head is also required. Slow TTFB delays when any painting can begin and is addressed through a CDN, server-side caching, or hosting upgrade. Render-blocking JavaScript and CSS prevent the LCP element from painting until they execute, resolved by deferring non-critical scripts and stylesheets.
INP Failures: JavaScript and Main Thread Congestion
INP failures are almost always main thread congestion. When the main thread is occupied processing JavaScript tasks, interactions queue up and wait, and INP captures every millisecond of that delay across the full session. Third-party scripts, including analytics platforms, ad libraries, and chat widgets, are the most common source, running synchronous tasks that compete directly with interaction handling. React hydration compounds this, keeping pages functionally unresponsive until JavaScript finishes setting up event handlers, even though the page looks complete to the user.
Resolving INP requires developer involvement in most cases. A Lighthouse audit under Avoid long main-thread tasks identifies the specific scripts causing congestion. Deferring or removing non-essential third-party tags is typically the fastest win, followed by breaking long tasks into chunks using setTimeout or scheduler.postTask. For computation that doesn’t need DOM access, web workers move the processing off the main thread entirely.
CLS Failures: Reserve Space, Load Fonts Stably
Adding explicit width and height attributes to every image and video element is the single most effective CLS fix. Without them, the browser collapses the layout until media loads and re-expands it on arrival, shifting everything below. For ad slots and iframes, reserving a minimum container height prevents the same collapse-and-expand pattern regardless of whether the content fills the space.
For web fonts, font-display: optional avoids swapping altogether if the font isn’t ready, while font-display: swap with a matched fallback font size minimises displacement during the swap. Dynamic content injected above the fold, such as cookie banners, notification bars, and auto-advancing carousels, should use CSS transform for animation rather than layout-affecting properties, keeping any movement out of the CLS calculation.
Why Mobile Core Web Vitals Matter More for Rankings
Google indexes the mobile version of a site first and uses mobile CWV data as its primary ranking input. With mobile pass rates at 48% versus 56% for desktop, the ranking gap is predominantly a mobile problem, and optimising desktop while mobile scores remain in the Needs Improvement or Poor band produces no ranking benefit.
Mobile performance is harder to achieve for structural reasons: variable network conditions that CDN delivery masks on desktop, slower JavaScript execution on budget and mid-range devices compared to lab testing environments, and smaller viewports that amplify CLS failures invisible at desktop width. A layout shift imperceptible at 1440px can shift the entire readable area on a 390px-wide screen. Checking mobile scores in Search Console and PageSpeed Insights before desktop is not optional for sites where rankings matter.
Frequently Asked Questions
Does a good Lighthouse score mean my Core Web Vitals are passing?
Lighthouse simulates one visit under controlled conditions and reflects none of the variability real Chrome users introduce: different devices, network speeds, and the full third-party script stack that fires on live visits. A Lighthouse performance score of 100 confirms the page performs well under those specific conditions, not that field data will show Good status. Actual CWV status should be checked in Google Search Console or the field data section at the top of a PageSpeed Insights report.
How long does it take to see Core Web Vitals improvements?
CrUX updates on a 28-day rolling window, so changes deployed today take up to four weeks to appear in Search Console or PageSpeed Insights field data. Checking Search Console within a week of a deployment tells you nothing useful. For faster directional feedback on whether a specific fix landed, Lighthouse or a real user monitoring tool with live data is the appropriate tool while waiting for field data to reflect the change.
Do Core Web Vitals affect rankings without CrUX data?
Pages with insufficient Chrome traffic to generate individual field data are assessed using origin-level data from comparable pages on the same site. This means the site’s overall CWV health affects pages that cannot yet be individually scored, because low-traffic pages inherit the origin-level baseline built by higher-traffic pages on the same domain.
Are Core Web Vitals more important than content quality?
Google’s own documentation confirms they are not: pages with the best information rank even when page experience is sub-par. CWV function as a tiebreaker in competitive SERPs where multiple pages target the same query at comparable quality, not as a signal that overrides content relevance. When choosing between content investment and CWV optimisation, the content comes first.
If you want assistance with GEO and SEO for LLMs, we are here for you! You can read more about our GEO services here, or contact us directly to learn how we can best support you in reaching your business goals.
