Core Web Vitals

TL;DR — Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. are three scores Google uses to measure how a page feels to real users: how fast it loads (LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good.), how quickly it responds when you tap or click (INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good.), and how much things jump around as it loads (CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good.). “Good” is LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. under 2.5 seconds, INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. under 200 milliseconds, and CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. under 0.1. They nudge rankings a little — but good content matters far more.

What Core Web Vitals are

Google wants to reward pages that are pleasant to use, so it boiled “good page experience” down to three measurable things. Together these are the Core Web Vitals (often shortened to CWV):

• Largest Contentful Paint (LCP) — loading. How long until the biggest thing on screen (usually a hero image or headline) shows up. Good is ≤ 2.5 seconds.
• Interaction to Next Paint (INP) — responsiveness. When you tap a button or type, how long before the page reacts. Good is ≤ 200 milliseconds.
• Cumulative Layout Shift (CLS) — visual stability. How much the page jumps around while it loads (an ad pushes the text down right as you go to tap). Good is ≤ 0.1.

Where the scores come from

The scores Google actually uses come from real people visiting your site in Chrome — not from a test you run. Google collects that data, and a page is judged on what 75% of visitors experienced. So you can’t “pass” by getting one fast result on your own machine; most of your real visitors have to have a good experience. Evidence for this claim Core Web Vitals are real-world experience metrics used by Google ranking systems; lab measurements are diagnostic and can differ from field measurements. Scope: Google Search use of Core Web Vitals and Chrome UX Report field data. Confidence: high · Verified: 2026-07-14 Google: Core Web Vitals and Search web.dev: Lab and field data

That’s why a perfect score in a speed-testing tool doesn’t guarantee you pass. Those tools (like PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. and LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal.) run a single lab test on a simulated phone — great for finding problems, but not the numbers Google ranks on.

Do they affect rankings?

Some. Google says Core Web VitalsWeb Vitals is Google's initiative (launched May 2020) for unified page-experience quality signals. Core Web Vitals — LCP, INP, and CLS — are the subset used in ranking; the rest (TTFB, FCP, TBT, Speed Index) are diagnostic, not ranking factors. are used by its ranking systems — but there’s no official weight or percentage attached to them, and Google is explicit that relevant content can still outrank a page with sub-par page experience. If your content isn’t relevant, fast and stable won’t save you. As Google’s John Mueller put it, “it’s not going to make your site’s rankings jump up.”

My honest take after years of this: most sites won’t see a big ranking benefit from chasing these numbers. But there’s nothing wrong with making your site faster and more stable — your visitors notice, and it helps conversions even when it doesn’t move rankings.

One thing people get wrong

Old name alert: you might still see FIDFirst Input Delay — a retired Core Web Vital that measured the delay before the browser could begin processing a page's first interaction. Good was ≤100 ms. Replaced by INP in March 2024. (First Input Delay) mentioned as a Core Web Vital. It’s gone — INP replaced FID on March 12, 2024. If a tool or article is still telling you to optimize FID, it’s out of date.

Want the deeper version — exact thresholds, field vs lab data, how much it really weighs for ranking, and which tool to use when? Switch to the Advanced tab.

TL;DR — Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. are three field-measured UX metrics: LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. (loading, “good” ≤ 2.5 s), INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. (responsiveness, ≤ 200 ms), and CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. (visual stability, ≤ 0.1), each judged at the 75th percentile of real Chrome users (CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program.) over a rolling 28-day window. Thresholds are the same for mobile and desktop, but Google assesses each separately, and expects all three metrics to be good — not just one. INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. replaced FIDFirst Input Delay — a retired Core Web Vital that measured the delay before the browser could begin processing a page's first interaction. Good was ≤100 ms. Replaced by INP in March 2024. on March 12, 2024. Google says its ranking systems use Core Web VitalsWeb Vitals is Google's initiative (launched May 2020) for unified page-experience quality signals. Core Web Vitals — LCP, INP, and CLS — are the subset used in ranking; the rest (TTFB, FCP, TBT, Speed Index) are diagnostic, not ranking factors., but there’s no official weight or “tiebreaker” percentage attached — a good score doesn’t guarantee better rankings, and relevance can still win. Lab scores (LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal./PSIPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking.) are diagnostic measurements and often don’t match field dataPerformance metrics captured from real users, not lab tests.. TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good. and FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital. are diagnostic “other Web Vitals”; TBTTotal Blocking Time — the sum of the blocking portion (time above 50 ms) of every long task between First Contentful Paint and Time to Interactive. It's a lab-recommended metric and the lab proxy for INP, not a Core Web Vital. and Speed IndexSpeed Index measures how quickly content is visually displayed during page load — the average time at which visible parts of the page appear, scored in seconds (lower is better). It's a lab-only Lighthouse metric, not a Core Web Vital and not a ranking factor. are lab proxies.

What counts as a Core Web Vital

Google defines Core Web Vitals as “the subset of Web Vitals that apply to all web pages, should be measured by all site owners, and will be surfaced across all Google tools.” There are exactly three, each measuring a different dimension of how a page feels:

Google evaluates the three “good” thresholds at the 75th percentile: LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. at 2.5 seconds, INP at 200 milliseconds, and CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. at 0.1. A page is only judged “good” overall once all three clear their bar at p75 — not just one or two. The thresholds themselves are the same for mobile and desktop, though Google assesses and reports each device class separately. Evidence for this claim Core Web Vitals are assessed at the 75th percentile, with good thresholds of 2.5 seconds for LCP, 200 milliseconds for INP, and 0.1 for CLS. Scope: Current stable Core Web Vitals definitions from the Chrome team. Confidence: high · Verified: 2026-07-14 web.dev: Web Vitals

Everything else you’ve heard of — TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good., FCP, TBT, Speed Index — is not a Core Web Vital. More on those below.

LCP — loading

LCP “reports the render time of the largest image, text block, or video visible in the viewport, relative to when the user first navigated to the page.” In practice the LCP element is usually a hero image, a big background image, or your headline block. Note it’s the largest visible element — different viewport sizes can have different LCP elements, which is one reason field and lab numbers diverge.

INP — responsiveness

INP “assesses a page’s overall responsiveness to user interactions by observing the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user’s visit to a page.” It measures the full interaction: input delay → event-handler processing → the time to paint the next frame.

This is the big improvement over the metric it replaced. INP improves on FID by observing all interactions, not just the first one — FID only timed the input delay of the very first interaction. INP became a Core Web Vital on March 12, 2024, replacing First Input Delay (FID). Evidence for this claim INP became a Core Web Vital and replaced FID on March 12, 2024. Scope: Chrome and Google tooling transition from FID to INP. Confidence: high · Verified: 2026-07-14 web.dev: INP launch FID was removed from Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance. that day. It is fully retired — don’t optimize for it.

One nuance worth holding onto: INP is not your worst single interaction, it’s a high percentile of all of them. A single janky click won’t tank an otherwise-good page.

CLS — visual stability

CLS “is a measure of the largest burst of layout shift scores for every unexpected layout shift that occurs during the entire lifecycle of a page.” The “burst” (session window) groups shifts that happen within 1 second of each other, up to a 5-second total window. The usual culprits Google names: “images or videos with unknown dimensions,” “fonts that render larger or smaller than its initial fallback,” and “third-party ads or widgets that dynamically resize themselves.”

Field data vs lab data — measurement and diagnosis

This is the distinction that causes the most confusion, so be precise about it.

• Field data (CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program.) is “data collected from the real users visiting your site.” It’s reported at the 75th percentile, over a rolling 28-day window, segmented across mobile and desktop. Core Web Vitals represent this kind of real-world experience and are used by Google’s ranking systems. It reflects real devices, networks, cache states, and back/forward cache.
• Lab data is “data collected in a controlled environment with predefined device and network settings” — a single emulated phone, cold cache, no real user. LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. and the PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. lab section produce this. It’s a diagnostic tool for finding problems rather than a field measurement. Evidence for this claim Core Web Vitals are real-world experience metrics used by Google ranking systems; lab measurements are diagnostic and can differ from field measurements. Scope: Google Search use of Core Web Vitals and Chrome UX Report field data. Confidence: high · Verified: 2026-07-14 Google: Core Web Vitals and Search web.dev: Lab and field data

Google’s own guidance: “If you have both field data and lab data for a given page, field data is what you should use to prioritize your efforts.” And the Performance Score from Lighthouse “often does not correlate with field Core Web Vitals.” I say the same thing in my Core Web Vitals guide: lab data is more useful for testing and iterating, because the field CWV data is on a 28-day rolling average — you won’t see your fix reflected for weeks.

The p75 rule, and why it matters

A page passes only if 75% of real users hit the “good” threshold. That’s a deliberately forgiving-but-real bar: most of your visitors (3 of 4) had a good experience, while you’re not held hostage to a few outliers on terrible connections. It’s also why your phone showing a 1.8s load means nothing on its own — your p75 across everyone is what counts.

Page-level vs origin-level — don’t get fooled

Many tools show you an origin-level (whole-site average) score by default, which can be far rosier than your individual pages. In my CWV data study (CrUX plus 5.2M pages from Ahrefs Site Audit), only 21.2% of individual pages passed all three thresholds, versus 33% at the origin level. Google’s page-experience documentation says its systems generally evaluate pages individually, though it also runs broader site-wide assessments — so an origin that “passes” can still be hiding plenty of failing individual pages. When a tool offers both views, don’t assume the origin-level average tells you what any specific page is doing; check the page-level number too.

A related gotcha: pages without enough traffic have no CrUX field data at all, and CrUX only includes Chrome users who’ve opted into usage stats (no iOS Chrome, no other browsers). That’s a data-eligibility gap, not a fail — missing field data isn’t the same as a poor score. Exactly how a given tool groups similar pages or falls back for low-traffic URLs (PSI, Search Console, the CrUX API) is documented by that specific product, not by one universal rule.

How much do Core Web Vitals actually matter for ranking?

They’re a confirmed ranking signal — Google says its ranking systems use Core Web Vitals. What Google’s current documentation does not do is attach an official weight, percentage, or “tiebreaker” label to that signal, so be careful about repeating those framings as if they were Google’s own words.

On the “it’s real” side: Google’s docs say Core Web Vitals “along with other page experience aspects, aligns with what our core ranking systems seek to reward,” and John Mueller went on record that it’s “more than a tie-breaker, but it also doesn’t replace relevance.”

On the “don’t overdo it” side: Mueller also said “Core Web Vitals are not giant factors in ranking, and I doubt you’d see a big drop just because of that,” and at the March 2024 documentation update added via LinkedIn that “it’s not going to make your site’s rankings jump up.” Google’s own page-experience docs are blunt: “Google Search always seeks to show the most relevant content, even if the page experience is sub-par.” The 2024 docs even warn that “trying to get a perfect score just for SEO reasons may not be the best use of your time.” Evidence for this claim Google says Core Web Vitals are used by ranking systems, while page experience does not override more relevant content. Scope: Google Search ranking guidance; no fixed weight or ranking-position effect is promised. Confidence: high · Verified: 2026-07-14 Google: Core Web Vitals and Search Google: Page experience

My pragmatic read: relevance dominates, Google hasn’t put a number on how much CWV counts, and most sites won’t see a great benefit from working on them for rankings. That said, the underlying UX improvements are worth doing for users and conversions — and platforms (WordPress, Cloudflare, frameworks) keep absorbing a lot of the optimization burden automatically. For small and local businesses especially, this usually shouldn’t be top of the list.

One more clarification from the 2024 update: of the broader page experience signals, only Core Web Vitals are confirmed to directly contribute to ranking. HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.', mobile-friendliness, no intrusive interstitialsIn SEO, interstitials are full-page popups or overlays that block the main content of a page. Google demotes pages with intrusive interstitials shown on the transition from a search click — a page-level signal, with legal gates, login walls, and small dismissible banners exempted., content clarity — all good practice, but they don’t directly boost ranking the way the docs once implied.

The “other Web Vitals” — diagnostic, not Core

These come up constantly and get miscategorized. None of them are Core Web Vitals:

• Time to First Byte (TTFB) — how long until the first byte of the response arrives. It “precedes every other meaningful loading performance metric” and feeds into LCP, but Google is explicit: “Because TTFB isn’t a Core Web Vitals metric, it’s not absolutely necessary that sites meet the ‘good’ TTFB threshold.” (Good ≤ 0.8 s.) Diagnostic.
• First Contentful Paint (FCP) — time until any content paints. A useful loading diagnostic (good ≤ 1.8 s), but not Core.
• Total Blocking Time (TBT) — a lab proxy for INP. Tools like Lighthouse “cannot measure INP” without a real user, so they report TBT instead. Lab only.
• Speed Index — a lab proxy for perceived load speed. Lighthouse-only.

Use these to debug. Don’t report them as Core Web Vitals or treat their thresholds as ranking gates.

A myth to retire

You may see “Engagement Reliability” floated as a new Core Web Vital. There is no official Google announcement for any such metric — it’s circulating in third-party content only. The Core Web Vitals are LCP, INP, and CLS. Until Google says otherwise, that’s the list.

How to measure — and which tool for what

Match the tool to the job:

• Ranking-relevant (field data): PageSpeed Insights (shows CrUX field data at page and origin level), Google Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results.’s Core Web Vitals reportThe Google Search Console report (under Experience) that shows how your indexed URLs perform on the Core Web Vitals — LCP, INP, and CLS — using real-user field data from CrUX, grouped by device, status, and clusters of similar-performing URLs. (groups similar pages, surfaces site-wide patterns), the CrUX API / BigQuery (custom and country-level analysis), and the web-vitals JS library (collect your own RUM).
• Debugging (lab data): Lighthouse, the Chrome DevTools Performance panelThe Performance panel is Chrome DevTools' built-in, local profiler for recording and analyzing how a page loads and runs — CPU, main-thread work, rendering, network, and live Core Web Vitals. The recorded trace is local, lab data from your own browser — not what Googlebot sees — though the panel can optionally show real-user CrUX field data alongside it., and the PSI lab section. These find the cause; they don’t decide your ranking.

The workflow I’d suggest: use GSC to find which page groups are failing in the field, confirm with PageSpeed Insights at the page level, then drop into Lighthouse / DevTools to diagnose and iterate — knowing the field numbers won’t update for up to 28 days.

Where to go next: the web performance cluster

This hub is the map. Each topic below is its own deep dive.

The three Core Web Vitals

• Largest Contentful Paint — the loading metric: what counts as the LCP element, the ≤2.5 s target, and how to make it paint sooner.
• Interaction to Next Paint — the responsiveness metric that replaced FID: input delay, event processing, and presentation delay, and how to cut each.
• Cumulative Layout Shift — the visual-stability metric: session windows, the usual causes (sized media, fonts, injected ads), and how to hit ≤0.1.

Supporting & diagnostic metrics

• Time to First Byte — server/response latency that feeds LCP; useful to debug, not a Core Web Vital.
• First Contentful Paint — when the first content paints; a loading diagnostic.
• Total Blocking Time — the lab proxy Lighthouse uses to approximate INP.
• Speed Index — the lab proxy for perceived load speed.

How they’re measured

• PageSpeed Insights — field (CrUX) data plus a Lighthouse lab report in one place.
• Google Lighthouse — the lab/diagnostic engine behind PSI and DevTools.
• Chrome UX Report (CrUX) — the real-user dataset Google’s assessment runs on.

For the whole cluster, see the Web Performance hub. Each sibling links here automatically as it ships.

AI summary

A condensed take on the Advanced version:

• Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. = three field metrics: LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. (loading, good ≤ 2.5 s), INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. (responsiveness, ≤ 200 ms), CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. (visual stability, ≤ 0.1). Everything else (TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good., FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital., TBTTotal Blocking Time — the sum of the blocking portion (time above 50 ms) of every long task between First Contentful Paint and Time to Interactive. It's a lab-recommended metric and the lab proxy for INP, not a Core Web Vital., Speed IndexSpeed Index measures how quickly content is visually displayed during page load — the average time at which visible parts of the page appear, scored in seconds (lower is better). It's a lab-only Lighthouse metric, not a Core Web Vital and not a ranking factor.) is not Core.
• Judged on field dataPerformance metrics captured from real users, not lab tests.: real Chrome users via CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program., at the 75th percentile, over a rolling 28-day window. Thresholds are the same for mobile/desktop but assessed separately, and Google expects all three metrics to be good, not just one.
• INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. replaced FID on March 12, 2024. FID is fully retired; INP measures all interactions, not just the first.
• Lab tools (LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal./PSI) are diagnostic, not field measurements, and often don’t match field CWV. Use them to find causes; field numbers lag up to 28 days.
• Page-level vs origin-level matters: ~21.2% of pages pass vs ~33% of origins (my CWV study). Google uses page-level — origin averages hide failing pages.
• Ranking weight: used, but unweighted. Google says its ranking systems use Core Web VitalsWeb Vitals is Google's initiative (launched May 2020) for unified page-experience quality signals. Core Web Vitals — LCP, INP, and CLS — are the subset used in ranking; the rest (TTFB, FCP, TBT, Speed Index) are diagnostic, not ranking factors., with no official percentage or “tiebreaker” label attached; relevance dominates and a good score isn’t a ranking guarantee. Mueller: “not giant factors in ranking.” Only CWV (not HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.', mobile-friendliness, interstitialsIn SEO, interstitials are full-page popups or overlays that block the main content of a page. Google demotes pages with intrusive interstitials shown on the transition from a search click — a page-level signal, with legal gates, login walls, and small dismissible banners exempted.) directly contributes per 2024 docs.
• Myth to skip: “Engagement Reliability” is not a confirmed Core Web Vital.
• Tooling: field = PSI, GSC CWV report, CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. API, web-vitals.js; debugging = Lighthouse, DevTools, PSI lab section.

Official documentation

Primary-source documentation from Google.

web.dev (Chrome team)

• Web Vitals — the initiative, the three metrics, the p75 rule, and why TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good./FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital. are “other” Web VitalsWeb Vitals is Google's initiative (launched May 2020) for unified page-experience quality signals. Core Web Vitals — LCP, INP, and CLS — are the subset used in ranking; the rest (TTFB, FCP, TBT, Speed Index) are diagnostic, not ranking factors..
• Largest Contentful Paint (LCP) — definition, thresholds, and qualifying LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. elements.
• Interaction to Next Paint (INP) — definition, thresholds, and the input-delay → processing → presentation breakdown.
• Cumulative Layout Shift (CLS) — definition, session windows, and common causes.
• Defining the Core Web Vitals metrics thresholds — why each “good” threshold and the 75th percentile were chosen.
• Lab and field data differences — why field (CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program.) and lab (LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal.) numbers diverge.
• Core Web Vitals workflows / tools — which tool reports field vs lab data.
• INP is advancing to Core Web Vitals (May 2023) — the announcement that INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. would replace FIDFirst Input Delay — a retired Core Web Vital that measured the delay before the browser could begin processing a page's first interaction. Good was ≤100 ms. Replaced by INP in March 2024..
• Interaction to Next Paint is officially a Core Web Vital (March 12, 2024) — the launch confirmation.
• TTFB and FCP — the diagnostic “other Web Vitals.”

Google Search Central

• Understanding Core Web Vitals and Google Search results — how CWV relate to ranking.
• Understanding page experience in Google Search results — the broader page-experience picture and the “relevance wins” framing.
• Introducing INP to Core Web Vitals (May 2023) — the Search Central announcement.

Chrome for Developers

• Chrome User Experience Report (CrUX) — the real-user dataset, eligibility, and the 28-day window.

Quotes from the source

On-the-record statements from Google. Each link is a deep link that jumps to the quoted passage on the source page.

Google — what Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. are

• “Core Web VitalsWeb Vitals is Google's initiative (launched May 2020) for unified page-experience quality signals. Core Web Vitals — LCP, INP, and CLS — are the subset used in ranking; the rest (TTFB, FCP, TBT, Speed Index) are diagnostic, not ranking factors. are the subset of Web Vitals that apply to all web pages, should be measured by all site owners, and will be surfaced across all Google tools.” — Philip Walton, web.dev. Jump to quote
• “LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. reports the render time of the largest image, text block, or video visible in the viewport, relative to when the user first navigated to the page.” — web.dev (LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good.). Jump to quote
• “INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. is a metric that assesses a page’s overall responsiveness to user interactions by observing the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user’s visit to a page.” — web.dev (INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good.). Jump to quote
• “CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. is a measure of the largest burst of layout shift scores for every unexpected layout shift that occurs during the entire lifecycle of a page.” — web.dev (CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good.). Jump to quote

Google — INP replacing FIDFirst Input Delay — a retired Core Web Vital that measured the delay before the browser could begin processing a page's first interaction. Good was ≤100 ms. Replaced by INP in March 2024.

• “Interaction to Next Paint (INP) is now a stable Core Web Vital metric, replacing First Input Delay (FID).” — Rick Viscomi, web.dev (March 12, 2024). Jump to quote

Google — field vs lab, and ranking

• “If you have both field dataPerformance metrics captured from real users, not lab tests. and lab data for a given page, field data is what you should use to prioritize your efforts.” — Philip Walton, web.dev. Jump to quote
• “The Chrome User Experience ReportChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. (also known as the Chrome UX Report, or CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. for short) is a dataset that reflects how real-world Chrome users experience popular destinations on the web.” — Chrome for Developers (CrUX docs). Jump to quote

John Mueller, Google

• “It is a ranking factor, and it’s more than a tie-breaker, but it also doesn’t replace relevance.” — via Search Engine Journal (Reddit, August 2021). Read the coverage
• “Core Web Vitals are not giant factors in ranking, and I doubt you’d see a big drop just because of that.” — via Stan Ventures (2024). Read the coverage

Core Web Vitals checklist

A quick pass to confirm you’re measuring the right thing and fixing the right pages:

• You’re reading field dataPerformance metrics captured from real users, not lab tests. (CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program.), not just a lab score, for the metrics Google ranks on.
• You’re looking at page-level numbers, not just the origin-level average.
• All three are checked: LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. ≤ 2.5 s, INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. ≤ 200 ms, CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. ≤ 0.1 at p75.
• Mobile and desktop are reviewed separately (Google assesses each).
• You’re not optimizing FIDFirst Input Delay — a retired Core Web Vital that measured the delay before the browser could begin processing a page's first interaction. Good was ≤100 ms. Replaced by INP in March 2024. — it was retired March 12, 2024 (use INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good.).
• GSC Core Web Vitals reportThe Google Search Console report (under Experience) that shows how your indexed URLs perform on the Core Web Vitals — LCP, INP, and CLS — using real-user field data from CrUX, grouped by device, status, and clusters of similar-performing URLs. reviewed for failing page groups, not one-offs.
• You understand low-traffic pages may have no CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. field data at all.
• Lab tools (LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal./PSIPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking.) are used to diagnose, not as the pass/fail gate — and you’re not waiting on a perfect Performance Score.
• You’re allowing up to 28 days for field fixes to show up.
• You’re not chasing CWV ahead of content relevance and bigger SEO wins.

The mental models

1. Three dimensions, three metrics. LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. = loading, INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. = responsiveness, CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. = visual stability. If you can name which dimension a problem lives in, you know which metric (and which deep dive) to open.

2. Field is for ranking; lab is for fixing. Google ranks on CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. field dataPerformance metrics captured from real users, not lab tests. at p75 over 28 days. LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal./PSIPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. lab scores find causes. Never treat a lab score as your ranking number — they often don’t even correlate.

3. Page-level beats origin-level. An origin that “passes” can hide failing pages. Google uses page-level data where it has it. When a tool shows both, trust the page-level view.

4. Used, but unweighted. CWV is a confirmed ranking signal that Google has never attached an official weight to — relevance can still override it. Fix CWV for users and conversions; don’t expect rankings to leap.

5. The “is it even Core?” test. Only LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good., INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good., CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. are Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data.. TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good. and FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital. are diagnostic; TBTTotal Blocking Time — the sum of the blocking portion (time above 50 ms) of every long task between First Contentful Paint and Time to Interactive. It's a lab-recommended metric and the lab proxy for INP, not a Core Web Vital. and Speed Index are lab proxies. “Engagement Reliability” is not confirmed at all.

Core Web Vitals — cheat sheet

The three Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. (field dataPerformance metrics captured from real users, not lab tests., p75)

Diagnostic metrics — NOT Core Web VitalsWeb Vitals is Google's initiative (launched May 2020) for unified page-experience quality signals. Core Web Vitals — LCP, INP, and CLS — are the subset used in ranking; the rest (TTFB, FCP, TBT, Speed Index) are diagnostic, not ranking factors.

Fast facts

• Assessment = CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. field data, 75th percentile, 28-day rolling window, mobile and desktop separately.
• INP replaced FID on March 12, 2024. FID is fully retired.
• Lab scores (LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal./PSI) are diagnostic, not field measurements — and often don’t match field CWV.
• Page-level is what Google uses; origin-level averages can mislead (~21.2% of pages pass vs ~33% of origins in my CWV study).
• Ranking weight: used by Google’s ranking systems, no official weight stated — relevance dominates and a good score is no guarantee.
• “Engagement Reliability” is not a confirmed Core Web Vital.

Which Core Web Vital should I investigate first?

Core Web Vitals regress after a release

1. Confirm the signal. Separate field from lab, URL from origin, and mobile from desktop. If only one lab run changed, reproduce it before declaring an incident.
2. Identify the failing vital. LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good., INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good., and CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. represent different problems. If multiple moved, check shared release changes and third-party scripts first.
3. Tie the regression to a deployment. Compare RUM or repeatable lab traces before and after the release. If timing does not align, inspect traffic/device mix instead.
4. Diagnose the metric, not the score. For LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. inspect element and sub-parts; for INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. inspect slow interactions and main-thread work; for CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. inspect shift sources.
5. Ship the smallest attributable fix. Validate it in the lab immediately. If it breaks functionality or worsens another vital, roll back.
6. Watch real users. Use RUM for the leading signal and CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program./Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. for the rolling field verdict. Document scope and window so stakeholders do not expect a same-day CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. reset.

Core Web Vitals mistakes that waste work

Optimizing the composite Lighthouse score

Google’s field assessment uses LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good., INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good., and CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. from real-user data, not the single LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. Performance number. Diagnose the failing field metric and use LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. as one controlled debugging environment.

Treating Core Web Vitals as a ranking shortcut

CWV are a page-experience signal Google has never assigned an official weight to; relevance still dominates. Fix poor experience for users, but do not promise a ranking jump or displace more important content and indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. work without evidence.

Mixing URL, origin, mobile, and desktop values

Different scopes can tell different stories. Label every value, and do not claim a page passes because an origin fallback or desktop aggregate is green.

Waiting on CrUX before checking a release

The rolling 28-day window is too slow for deployment QA. Validate the mechanism in the lab and RUM immediately, then use CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. to confirm the longer field outcome.

Tools for measuring Core Web Vitals

Check it with the Core Web Vitals History & Competitor Comparison:

1. Add a site (a bare origin like example.com has the most CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. data; add up to 5 to compare).
2. Pick mobile or desktop, then run the comparison.
3. Read the scorecard for today’s pass/fail on LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good., INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good., and CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good., then the weekly trend chart to see whether each metric is heading toward or away from the good band.

Field dataPerformance metrics captured from real users, not lab tests. — real-user Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. measurement

• PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. — CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. field data at page and origin level, plus a LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. lab report alongside it.
• Google Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. — Core Web Vitals reportThe Google Search Console report (under Experience) that shows how your indexed URLs perform on the Core Web Vitals — LCP, INP, and CLS — using real-user field data from CrUX, grouped by device, status, and clusters of similar-performing URLs. — groups similar pages and surfaces site-wide field patterns; the fastest way to find failing page groups.
• CrUX API / BigQuery — custom and country-level analysis straight from the source dataset.
• web-vitals JavaScript library — collect your own real-user (RUM) data, e.g. pipe it into analytics.

Lab data — for debugging (not ranking)

• LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. — diagnostic opportunities and the (non-ranking) Performance Score.
• Chrome DevTools Performance panelThe Performance panel is Chrome DevTools' built-in, local profiler for recording and analyzing how a page loads and runs — CPU, main-thread work, rendering, network, and live Core Web Vitals. The recorded trace is local, lab data from your own browser — not what Googlebot sees — though the panel can optionally show real-user CrUX field data alongside it. — trace-level debugging of LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good., layout shifts, and long tasksAny main-thread task over 50 ms — the primary cause of INP regressions..
• PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. lab section — the Lighthouse-powered recommendations under the field data.

Rule of thumb: GSC to find where you’re failing in the field → PSI to confirm at the page level → Lighthouse / DevTools to diagnose and iterate.

Resources worth your time

My related writing

• Core Web Vitals: How to Improve Them (Ahrefs) — my full practical guide to the three metrics and what to fix.
• Core Web Vitals Data Study (Ahrefs) — CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. + 5.2M pages; the page-level vs origin-level pass-rate finding.
• Largest Contentful Paint (LCP) guide (Ahrefs).
• Cumulative Layout Shift (CLS) guide (Ahrefs).
• PageSpeed Insights guide (Ahrefs).
• The Beginner’s Guide to Technical SEO — where page experience fits in the bigger picture.

Official

• web.dev — Web Vitals and the per-metric articles linked under Official Docs.
• Google updates its page experience docs to clarify ranking signals (Search Engine Land) — Barry Schwartz on the March 2024 documentation change.

From around the industry

• Google Core Web Vitals Ranking Factor: More Than a Tie-Breaker (Search Engine Journal) — coverage of John Mueller’s Reddit statement that CWV is “more than a tie-breaker” but doesn’t replace relevance.
• Google Core Web Vitals Priority for Small/Local Businesses (Search Engine Roundtable) — Mueller’s Mastodon comment that CWV work should not be top priority for small/local businesses.
• Confirmed: Core Web Vitals Not a Big Ranking Factor (Stan Ventures) — Mueller’s “not giant factors in ranking” quote in context.
• Impact of Core Web Vitals on SEO (RUMvision) — updated Nov 2025; thorough FAQ-style roundup of rep quotes and ranking-signal nuance.
• Google Page Experience Update: Tiebreaker (Search Engine Roundtable) — early Mueller/Illyes tiebreaker framing from before the update launched.

Stats worth citing

• Only ~21.2% of individual pages pass all three Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. — versus ~33% at the origin level — from my CWV data study (CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. + 5.2M pages from Ahrefs Site Audit). Google’s systems generally evaluate pages individually, so a rosy origin-level average can still hide plenty of failing pages. Source
• Sites struggle most with LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good.. That study foundA 302 (\"Found\") is a temporary redirect: it forwards users to a new URL while telling search engines the original URL should stay in the index. It's a weak canonicalization signal, not the zero-equity dead end of SEO folklore. sites making progress on the old FIDFirst Input Delay — a retired Core Web Vital that measured the delay before the browser could begin processing a page's first interaction. Good was ≤100 ms. Replaced by INP in March 2024. and on CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good., but lagging on LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. — and “almost no sites on 3G or slower connections are passing.” Source
• The “good” thresholds: LCP ≤2.5 s, INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. ≤200 ms, CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. ≤0.1, each at the 75th percentile of field dataPerformance metrics captured from real users, not lab tests. — Google’s documented Core Web VitalsWeb Vitals is Google's initiative (launched May 2020) for unified page-experience quality signals. Core Web Vitals — LCP, INP, and CLS — are the subset used in ranking; the rest (TTFB, FCP, TBT, Speed Index) are diagnostic, not ranking factors. targets. Source
• INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. replaced FID on March 12, 2024 — the date FID stopped being a Core Web Vital and was removed from Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results.. Source

Test yourself: Core Web Vitals

Five quick questions on Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data.. Pick an answer for each, then check.

Prove an LCP/INP/CLS fix actually landed

The trap with a performance fix is celebrating the lab score the day you ship. Lab (LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal.) tells you if the change can work; only field dataPerformance metrics captured from real users, not lab tests. (CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program.) tells you if it worked for real users — and it moves on a 28-day rolling delay. Run both, in that order.

Test 1 — The fix improved the lab metric

• Test to run — Run the page through the Core Web Vitals Checker (or LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. / PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking.) before and after the change.
• Expected result — The targeted lab metric moves the right way — e.g. LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. element renders sooner, no new layout shiftCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good., the specific diagnostic you were fixing clears.
• Failure interpretation — No lab movement means the change didn’t touch the critical path (you optimized an element that wasn’t the LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. element, or a script that wasn’t blocking).
• Monitoring window — Immediate — lab tests run on demand.
• Rollback trigger — A regression in another metric (you fixed LCP but introduced CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good., or added JS that hurt INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good.) — lab catches this before real users do.

Test 2 — Real users actually feel it (field data)

• Test to run — Track the page/origin’s p75 for LCP, INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good., and CLS in CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. — the Core Web Vitals History & Competitor Comparison or the GSC Core Web Vitals reportThe Google Search Console report (under Experience) that shows how your indexed URLs perform on the Core Web Vitals — LCP, INP, and CLS — using real-user field data from CrUX, grouped by device, status, and clusters of similar-performing URLs..
• Expected result — p75 for the fixed metric crosses into “Good” and stays there (Google’s thresholds: LCP ≤ 2.5s, INP ≤ 200ms, CLS ≤ 0.1).
• Failure interpretation — Lab improved but field didn’t — the fix helped a fast-connection test but not the real device/network mix, or not enough URLs in the group share the fix.
• Monitoring window — 28-day rolling — CrUX is a trailing 28-day window, so a fix needs ~4 weeks of accumulated field data before the p75 is trustworthy. Don’t call it on week one.
• Rollback trigger — p75 crosses back over the “poor” threshold, or the “Good” URL count in GSCA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. falls after a template change — a strong sign the deploy regressed real-user performance.

The standing KPI for this topic

Separate from validating any one fix, this is what you watch quarter over quarter to know page experience is healthy. There is a defensible benchmark here — Google publishes the thresholds — so no numbers are invented.

p75 LCP, INP, and CLS (field data)

• Metric — The 75th-percentile value of each Core Web Vital across real visits, per page group and device.
• What it tells you — Whether 75% of real users get a good experience — the exact bar Google uses to classify a URL as passing. p75 (not the average) is the number that matters because it reflects the slower long tail.
• How to pull it — CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. via the Core Web Vitals History & Competitor Comparison, the GSCA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. Core Web Vitals report (field dataPerformance metrics captured from real users, not lab tests. grouped by URL pattern), or PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. for a single URL.
• Benchmark / realistic range — Google’s own thresholds: LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. ≤ 2.5s, INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. ≤ 200ms, CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. ≤ 0.1 for “Good”; the “Needs improvement” / “Poor” bands are 2.5–4s / >4s, 200–500ms /

  500ms, and 0.1–0.25 / >0.25. These are the published lines, not a made-up target.

• Cadence — 28-day rolling, so review monthly — checking daily just re-reads the same trailing window. Treat lab scores as the leading indicator and CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. p75 as the lagging one.

”Good URL” coverage across the site

• Metric — The share of your indexedStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. URLs in the “Good” bucket of the GSC Core Web Vitals report (mobile and desktop tracked separately).
• What it tells you — How broadly the fixes have propagated — a single fast page doesn’t move the site; template-level wins do.
• How to pull it — GSC → Core Web Vitals reportThe Google Search Console report (under Experience) that shows how your indexed URLs perform on the Core Web Vitals — LCP, INP, and CLS — using real-user field data from CrUX, grouped by device, status, and clusters of similar-performing URLs. → count of Good / Needs improvement / Poor URLs over time.
• Benchmark / realistic range — Situational — it depends on your templates and traffic mix, so establish your own baseline and drive the Good share up over time rather than chasing an invented percentage.
• Cadence — Monthly, or weekly right after a template/theme change while the field window catches up.

Core Web Vitals

Google's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data.

Related: LCP, INP, CLS, CrUX

Core Web Vitals

Core Web VitalsWeb Vitals is Google's initiative (launched May 2020) for unified page-experience quality signals. Core Web Vitals — LCP, INP, and CLS — are the subset used in ranking; the rest (TTFB, FCP, TBT, Speed Index) are diagnostic, not ranking factors. (CWV) are the three real-world, user-experience metrics Google uses to measure how a page feels to use: Largest Contentful PaintLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. (LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good.) for loading, Interaction to Next PaintInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. (INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good.) for responsiveness, and Cumulative Layout ShiftCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. (CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good.) for visual stability. They’re the subset of Google’s broader “Web Vitals” program that applies to every page — and the only page-experience signals Google explicitly confirms its ranking systems use.

The “good” targets are LCP ≤ 2.5 s, INP ≤ 200 ms, and CLS ≤ 0.1, each judged at the 75th percentile of real users — Google expects all three to be good, not just one. Thresholds are the same for mobile and desktop, though Google assesses each separately. Assessment runs on field dataPerformance metrics captured from real users, not lab tests. from the Chrome User Experience ReportChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. (CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program.) over a rolling 28-day window — not on lab scores from LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. or PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking., which are diagnostic tools. INP replaced First Input DelayFirst Input Delay — a retired Core Web Vital that measured the delay before the browser could begin processing a page's first interaction. Good was ≤100 ms. Replaced by INP in March 2024. (FID) as a Core Web Vital on March 12, 2024; FID is fully retired.

CWV are a real, confirmed ranking signal, but Google has never attached an official weight or “tiebreaker” percentage to it. Google reps have been clear that relevance matters far more, and that chasing a perfect score for SEO alone is rarely the best use of your time. TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good. and FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital. are related “other Web Vitals” used for diagnosis (not Core); TBTTotal Blocking Time — the sum of the blocking portion (time above 50 ms) of every long task between First Contentful Paint and Time to Interactive. It's a lab-recommended metric and the lab proxy for INP, not a Core Web Vital. and Speed IndexSpeed Index measures how quickly content is visually displayed during page load — the average time at which visible parts of the page appear, scored in seconds (lower is better). It's a lab-only Lighthouse metric, not a Core Web Vital and not a ranking factor. are lab proxies.

Related: LCP, INP, CLS, CrUX

Changelog