Core Web Vitals

TL;DR — Core Web Vitals are three scores Google uses to measure how a page feels to real users: how fast it loads (LCP), how quickly it responds when you tap or click (INP), and how much things jump around as it loads (CLS). “Good” is LCP under 2.5 seconds, INP under 200 milliseconds, and CLS 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 Insights and Lighthouse) 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 Vitals 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 FID (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 Vitals are three field-measured UX metrics: LCP (loading, “good” ≤ 2.5 s), INP (responsiveness, ≤ 200 ms), and CLS (visual stability, ≤ 0.1), each judged at the 75th percentile of real Chrome users (CrUX) 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. INP replaced FID on March 12, 2024. Google says its ranking systems use Core Web Vitals, 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 (Lighthouse/PSI) are diagnostic measurements and often don’t match field data. TTFB and FCP are diagnostic “other Web Vitals”; TBT and Speed Index 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: LCP at 2.5 seconds, INP at 200 milliseconds, and CLS 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 — TTFB, 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 Console 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 (CrUX) 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. Lighthouse and the PageSpeed Insights 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. HTTPS, mobile-friendliness, no intrusive interstitials, 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 Console’s Core Web Vitals report (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 panel, 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 Vitals = three field metrics: LCP (loading, good ≤ 2.5 s), INP (responsiveness, ≤ 200 ms), CLS (visual stability, ≤ 0.1). Everything else (TTFB, FCP, TBT, Speed Index) is not Core.
• Judged on field data: real Chrome users via CrUX, 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.
• INP replaced FID on March 12, 2024. FID is fully retired; INP measures all interactions, not just the first.
• Lab tools (Lighthouse/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 Vitals, 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 HTTPS, mobile-friendliness, interstitials) directly contributes per 2024 docs.
• Myth to skip: “Engagement Reliability” is not a confirmed Core Web Vital.
• Tooling: field = PSI, GSC CWV report, CrUX 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 TTFB/FCP are “other” Web Vitals.
• Largest Contentful Paint (LCP) — definition, thresholds, and qualifying LCP 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 (CrUX) and lab (Lighthouse) 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 INP would replace FID.
• 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 Vitals are

• “Core Web Vitals 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
• “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.” — web.dev (LCP). Jump to quote
• “INP 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 (INP). Jump to quote
• “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.” — web.dev (CLS). Jump to quote

Google — INP replacing FID

• “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 data 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 Report (also known as the Chrome UX Report, or CrUX 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 data (CrUX), 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: LCP ≤ 2.5 s, INP ≤ 200 ms, CLS ≤ 0.1 at p75.
• Mobile and desktop are reviewed separately (Google assesses each).
• You’re not optimizing FID — it was retired March 12, 2024 (use INP).
• GSC Core Web Vitals report reviewed for failing page groups, not one-offs.
• You understand low-traffic pages may have no CrUX field data at all.
• Lab tools (Lighthouse/PSI) 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. LCP = loading, INP = responsiveness, CLS = 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 CrUX field data at p75 over 28 days. Lighthouse/PSI 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 LCP, INP, CLS are Core Web Vitals. TTFB and FCP are diagnostic; TBT and Speed Index are lab proxies. “Engagement Reliability” is not confirmed at all.

Core Web Vitals — cheat sheet

The three Core Web Vitals (field data, p75)

Diagnostic metrics — NOT Core Web Vitals

Fast facts

• Assessment = CrUX 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 (Lighthouse/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. LCP, INP, and CLS 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 LCP inspect element and sub-parts; for INP inspect slow interactions and main-thread work; for CLS 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 CrUX/Search Console for the rolling field verdict. Document scope and window so stakeholders do not expect a same-day CrUX reset.

Core Web Vitals mistakes that waste work

Optimizing the composite Lighthouse score

Google’s field assessment uses LCP, INP, and CLS from real-user data, not the single Lighthouse Performance number. Diagnose the failing field metric and use Lighthouse 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 indexing 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 CrUX 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 CrUX 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 LCP, INP, and CLS, then the weekly trend chart to see whether each metric is heading toward or away from the good band.

Field data — real-user Core Web Vitals measurement

• PageSpeed Insights — CrUX field data at page and origin level, plus a Lighthouse lab report alongside it.
• Google Search Console — Core Web Vitals report — 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)

• Lighthouse — diagnostic opportunities and the (non-ranking) Performance Score.
• Chrome DevTools Performance panel — trace-level debugging of LCP, layout shifts, and long tasks.
• PageSpeed Insights 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) — CrUX + 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 Vitals — versus ~33% at the origin level — from my CWV data study (CrUX + 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 LCP. That study found sites making progress on the old FID and on CLS, but lagging on LCP — and “almost no sites on 3G or slower connections are passing.” Source
• The “good” thresholds: LCP ≤2.5 s, INP ≤200 ms, CLS ≤0.1, each at the 75th percentile of field data — Google’s documented Core Web Vitals targets. Source
• INP replaced FID on March 12, 2024 — the date FID stopped being a Core Web Vital and was removed from Search Console. Source

Test yourself: Core Web Vitals

Five quick questions on Core Web Vitals. 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 (Lighthouse) tells you if the change can work; only field data (CrUX) 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 Lighthouse / PageSpeed Insights) before and after the change.
• Expected result — The targeted lab metric moves the right way — e.g. LCP element renders sooner, no new layout shift, 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 LCP 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 CLS, or added JS that hurt INP) — 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, INP, and CLS in CrUX — the Core Web Vitals History & Competitor Comparison or the GSC Core Web Vitals report.
• 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 GSC 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 — CrUX via the Core Web Vitals History & Competitor Comparison, the GSC Core Web Vitals report (field data grouped by URL pattern), or PageSpeed Insights for a single URL.
• Benchmark / realistic range — Google’s own thresholds: LCP ≤ 2.5s, INP ≤ 200ms, CLS ≤ 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 CrUX p75 as the lagging one.

”Good URL” coverage across the site

• Metric — The share of your indexed 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 report → 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 Vitals (CWV) are the three real-world, user-experience metrics Google uses to measure how a page feels to use: Largest Contentful Paint (LCP) for loading, Interaction to Next Paint (INP) for responsiveness, and Cumulative Layout Shift (CLS) 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 data from the Chrome User Experience Report (CrUX) over a rolling 28-day window — not on lab scores from Lighthouse or PageSpeed Insights, which are diagnostic tools. INP replaced First Input Delay (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. TTFB and FCP are related “other Web Vitals” used for diagnosis (not Core); TBT and Speed Index are lab proxies.

Related: LCP, INP, CLS, CrUX

Changelog