Web Vitals

TL;DR — “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.” is Google’s name for its whole set of page-experience metrics. “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 just the three of them that actually affect rankings: 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), 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). Metrics like 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., 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 also Web Vitals — they’re handy for diagnosing problems, but they don’t move your rankings.

What Web Vitals is

Google launched Web Vitals in 2020 to fix a real problem: there were dozens of ways to measure how fast and smooth a page felt, and nobody agreed on which ones mattered. Web Vitals is Google’s answer — a single, named set of quality signals so everyone can point at the same things.

The most important thing to understand is that Web Vitals and 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 not the same thing:

• Web Vitals is the whole umbrella — every metric in the program.
• Core Web Vitals are the three that Google says apply to every page and uses in its ranking systems.

The three Core Web Vitals

These are the ones that count for SEO:

• 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. (Largest Contentful Paint) — how long until the biggest thing on screen loads. Aim for 2.5 seconds or less.
• INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. (Interaction to Next Paint) — how quickly the page responds when you tap or click. Aim for 200 milliseconds or less.
• 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. (Cumulative Layout Shift) — how much the page jumps around as it loads. Aim for 0.1 or less.

If you’ve heard of FID (First Input Delay), that’s the old one — INP replaced it in March 2024. Stop optimizing for FID.

The other Web Vitals

You’ll keep bumping into names like 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., and Speed Index in 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.. These are also Web Vitals — but they’re diagnostic. They help you figure out why a Core metric is bad. They are not Core Web Vitals and they don’t directly affect rankings.

The thing most people get wrong

A perfect PageSpeed/Lighthouse score doesn’t mean you pass Core Web Vitals. Those tools run a single lab test on a simulated phone. Google actually ranks on field dataPerformance metrics captured from real users, not lab tests. — what real Chrome users experience on your page. That’s why your Lighthouse number and your Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance. report often disagree, and the Search Console one is the one that matters for ranking.

Want the full taxonomy, the field-vs-lab story, and the honest take on how much Core Web Vitals really move rankings? Switch to the Advanced tab.

TL;DR — 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. is Google’s umbrella initiative (May 2020); Core Web Vitals (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 the stable subset that feeds ranking. 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. The “other” Web Vitals — 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. — are diagnostic, more experimental, and not ranking factors. Google ranks on 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., 75th percentile, page-level where available), not lab scores — which is why 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 Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance. disagree. Ranking weight is confirmed but lightweight: Mueller calls it “more than a tie-breaker” but “not giant factors.” Bing has no equivalent program.

Web Vitals is the initiative, not the metric

Google’s own definition: “Web Vitals is an initiative by Google to provide unified guidance for quality signals that are essential to delivering a great user experience on the web.” The whole point was to cut through metric overwhelm — by 2020 there were a dozen ways to score a page and no agreement on which to trust.

The program is two tiers, and conflating them is the single most common mistake I see:

• 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. — “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.” These are 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., INP, 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., and they’re the ones in Google’s ranking systems.
• Other Web Vitals — supplementary, often tool- or context-specific metrics that “can serve as proxy—or as supplemental metrics for the three Core Web Vitals—to help capture a larger part of the experience or to aid in diagnosing a specific issue.” Google is explicit that “their definitions and thresholds may change with greater frequency” than the Core set.

That lifecycle distinction matters. Google tracks Core Web Vitals candidates through three phases — experimental, pending, then stable — before they count. Core Web Vitals are at the Stable stage — “actively supported” and they “won’t change more than once per year.” INP followed that exact runway: it moved from experimental to pending on May 10, 2023, then became stable on March 12, 2024, replacing FID. That’s why swapping FID for INP took a long, telegraphed runway, while the diagnostic metrics can shift quietly.

Core Web Vitals — the three that rank

INP became a Core Web Vital on March 12, 2024, replacing FID. FID was removed from Search Console that day and Chrome tool support ended September 9, 2024 — it’s fully retired. Any article or dashboard still listing FID as a current Core Web Vital is out of date.

The Core trio gets its own deep dive — see 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. for thresholds, the 75th-percentile rule, and how to improve each one. This hub is about the whole initiative, including the metrics that sit underneath it.

TIP Fix the failing Core Web Vital instead of chasing one composite score

This sample fails because LCP is the priority. INP and CLS need separate evidence and different fixes on pages where they fail.

Check the three field metrics with my free Page Speed Test Free

1. Test the live URL and identify which of LCP, INP, or CLS fails.
2. Follow the metric-specific recommendation rather than applying a generic speed fix.
3. Verify the candidate cause in a lab trace, then wait for field data to reflect the deployed change.

Tap to enlarge

The result says the page fails Core Web Vitals and lists improve the Largest Contentful Paint as the first fix. It recommends optimizing and preloading the hero image, then verifying the LCP element in a fresh lab trace.

Other Web Vitals — the diagnostic layer

This is the section most “web vitals” articles skip or mangle. These four are real Web Vitals, they show up constantly in your tooling, and none of them is a ranking factor:

The trap is that TBT and Speed Index don’t exist in the field at all — there’s no CrUX value for them. They’re Lighthouse-computed proxies. TBT approximates INP (Lighthouse can’t measure real interactions, so it measures how long the main thread is blocked instead); a low TBT usually means a low INP, but they’re not the same number. Speed Index is a perceived-speed proxy weighted at roughly 10% of the Lighthouse Performance Score. Google itself notes about TTFB: “Because TTFB isn’t a Core Web Vitals metric, it’s not absolutely necessary that sites meet the ‘good’ TTFB threshold.”

Field data is what Google ranks on

This is the distinction that resolves most “why don’t my numbers match” confusion. Lab data is a single synthetic test — Lighthouse, DevTools, the lab section of 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. — run on a simulated device with a cold cache. Field data is the Chrome User Experience Report (CrUX): real Chrome users, aggregated at the 75th percentile over a 28-day rolling window, split by mobile and desktop.

Google ranks on the field data. As Philip Walton put it, “If you have both field data and lab data for a given page, field data is what you should use to prioritize your efforts.” So a 100 Performance Score in Lighthouse doesn’t mean your real users pass, and a failing lab score doesn’t necessarily mean you’re failing rankings. Use lab tools to diagnose, CrUX to judge.

One more thing the top-ranking pages almost never mention: Google uses page-level CrUX data where there’s enough of it, not the origin-level (whole-site) average. That matters a lot. In my Core Web Vitals data study (CrUX plus 5.2M pages), only 21.2% of individual pages passed all three Core Web Vitals versus 33% at the origin level. The origin average flatters you — Google ranks the page.

Do Web Vitals affect rankings? (Honestly.)

Only the three Core Web Vitals are confirmed ranking signals. Google’s own FAQ says it plainly: “Core Web Vitals are used by our ranking systems.” But Google doesn’t publish a percentage, a fixed weight, or a formal tiebreaker mechanism anywhere — its own docs say “there is no single signal. Our core ranking systems look at a variety of signals that align with overall page experience.” The closest thing to a weight estimate comes from John Mueller’s own characterization, not an official doc: “it’s a ranking factor, and it’s more than a tie-breaker, but it also doesn’t replace relevance,” and separately, “Core Web Vitals are not giant factors in ranking.” Google’s own docs go further: “Trying to get a perfect score just for SEO reasons may not be the best use of your time,” and “Google Search always seeks to show the most relevant content, even if the page experience is sub-par.”

So: fix Core Web Vitals because they’re genuinely good for users and because Google confirms they factor into ranking — not because a green score guarantees a jump in position. As Google’s own FAQ puts it, good scores in reports like Search Console or third-party tools “doesn’t guarantee that your pages will rank at the top of Google Search results.”

Does Bing use Web Vitals?

No. Bing has no equivalent to Core Web Vitals and doesn’t use Google’s LCP/INP/CLS framework as a formal ranking signal. It still values fast, usable pages — but it leans on behavioral signals (click-through, dwell time, bounce) as its quality proxies rather than a CrUX-style field assessment. Optimizing Core Web Vitals helps Bing indirectly (faster pages → better behavior) but there’s no proprietary Bing program to chase.

The state of Web Vitals in 2026

As of the May 2026 CrUX release, 55.9% of tracked origins pass all three Core Web Vitals. LCP remains the hardest (≈68.6% good) and INP the easiest now that sites have adapted to the FID transition (≈86.6% good). There are no confirmed new Core Web Vitals coming — claims about a “Visual Stability Index” or similar are third-party speculation with no official Google announcement, so treat them as unconfirmed until Google says otherwise.

Where to go next

This hub is the map. The Core trio has its own 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. deep dive; below are the supplementary metrics that sit under this initiative, each nested under this hub:

• First Contentful Paint — when the first content paints (≤ 1.8 s good); a loading diagnostic that often explains a slow LCP, but not a Core Web Vital.
• Time to First Byte — server response latency that precedes FCP and LCP (≤ 0.8 s good); fix it to help LCP, but TTFB itself isn’t a ranking factor.
• Total Blocking Time — the lab-only proxy for INP (< 200 ms good); how long the main thread was blocked, used to debug responsiveness when you can’t measure real interactions.
• Speed Index — the lab-only perceived-load-speed metric (≤ 3.4 s good) computed from a video of the page loading; roughly 10% of the Lighthouse score.

For the field-data backbone everything here rests on, see 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 for the broader picture, Web Performance.

AI summary

A condensed take on the Advanced version:

• 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. = the initiative (Google, May 2020) for unified page-experience signals. 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. = the ranking subset: 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, ≤ 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). They are not synonyms.
• 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; FID is fully retired.
• Other Web Vitals are diagnostic, not ranking factors: 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. (≤ 0.8 s), 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. (≤ 1.8 s), 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. (< 200 ms, lab-only INP proxy), 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. (≤ 3.4 s, lab-only perceived-speed proxy, ~10% of the 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. score).
• Google ranks on 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 lab scores — 75th percentile, 28-day window, mobile/desktop split. Lab tools (Lighthouse, DevTools) are for diagnosing; that’s why your Lighthouse number and Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance. disagree.
• Page-level, not origin-level, is what Google uses. Patrick’s study: 21.2% of pages pass vs. 33% of origins — the origin average flatters you.
• Ranking weight is confirmed but lightweight. Mueller: “more than a tie-breaker” but “not giant factors”; relevance dominates.
• Bing has no equivalent 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. program; it uses behavioral signals.
• 2026: 55.9% of origins pass all three (CrUX, May 2026); 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. hardest, INP easiest. No confirmed new Core Web Vitals.

Official documentation

Primary-source documentation on the 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. initiative and its metrics.

Google / web.dev

• Web Vitals (initiative overview) — the definition, the Core vs. other tiers, and the lifecycle (Stable, experimental).
• Core Web Vitals and Google Search results — how 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. factor into ranking.
• Understanding page experience in Google Search — the “relevance still wins” and “perfect score may not be worth it” guidance.
• Largest Contentful Paint (LCP) · Interaction to Next Paint (INP) · Cumulative Layout Shift (CLS) — 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..
• First Contentful Paint (FCP) · Time to First Byte (TTFB) · Total Blocking Time (TBT) — the supplementary metrics’ official definitions.
• Lab and field data differences — why your tools disagree and which data to trust.
• INP is officially a Core Web Vital — the March 12, 2024 launch that retired 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..
• Chrome User Experience Report (CrUX) — the field dataset Google ranks on.
• Web Vitals tools — which tool reports which metric.

Bing / Microsoft

• Bing publishes no Core Web Vitals equivalent. Its Webmaster Guidelines cover page speed and usability in general terms rather than a 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.-style field framework.

Quotes from the source

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

Google / web.dev — what the initiative is

• “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. is an initiative by Google to provide unified guidance for quality signals that are essential to delivering a great user experience on the web.” Jump to quote
• “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 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.” Jump to quote
• “The other Web Vitals are often context or tool specific, and may be more experimental than the 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.. As such, their definitions and thresholds may change with greater frequency.” Jump to quote

Google — 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 not Core Web Vitals

• “Because 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. isn’t a Core Web Vitals metric, it’s not absolutely necessary that sites meet the ‘good’ TTFB threshold, provided that it doesn’t impede their ability to score well on the metrics that matter.” Jump to quote
• “A low 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. often correlates with a low 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.).” Jump to quote

Google — field dataPerformance metrics captured from real users, not lab tests. is what to trust

• “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. Jump to quote

Google — ranking mechanics (no published weight)

• “Core Web Vitals are used by our ranking systems.” Jump to quote
• “There is no single signal. Our core ranking systems look at a variety of signals that align with overall page experience.” Jump to quote
• “[Good scores] doesn’t guarantee that your pages will rank at the top of Google Search results.” Jump to quote

Rick Viscomi, Google Chrome — INP replaces 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.

• “Starting today, INP is no longer experimental and will instead be considered a pending Core Web Vital metric.” — May 10, 2023 announcement. Jump to quote
• “Interaction to Next Paint (INP) is now a stable Core Web Vital metric, replacing First Input Delay (FID).” — March 12, 2024 launch. Jump to quote

John Mueller, Google — the ranking weight

• “It is a ranking factor, and it’s more than a tie-breaker, but it also doesn’t replace relevance.” 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.” Read the coverage

Web Vitals mistakes that lead to the wrong work

• Using “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.” and “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.” interchangeably. The broader initiative contains diagnostic metrics; 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., 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. are the current Core set used in ranking.
• Reporting 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 the ranking result. 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. is a synthetic lab test. Google uses 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. for the 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. signal, so the two answer different questions.
• Optimizing the origin average while weak templates fail. Origin-level data can hide a poor product, article, or checkout template. Segment URLs by template and inspect page-level or grouped field data where available.
• Averaging away the slow users. Core Web Vitals assessment uses the 75th percentile, not the mean. Report the same percentile that the assessment uses.
• Keeping 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 the current scorecard. INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. replaced FID in March 2024. Historical FID trends may be context, but they are not the current responsiveness target.

Web Vitals map

Core Web Vitals program scorecard

Metric: Passing URLs and user experiences 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., 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., segmented by page template and device class.

What it tells you: Whether real visitors receive a good loading, responsiveness, and visual-stability experience, and whether one template is hiding behind a healthy origin aggregate.

How to pull it: Use 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. for issue groups and 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. 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 URL- and origin-level field distributions. 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. or DevTools only to diagnose the causes behind a field result.

Benchmark or realistic range: Use Google’s published “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 or less, INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. at 200 milliseconds or less, 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 or less. Do not invent a universal 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.-score target.

Cadence: Monitor field trends by release and review the rolling field window after meaningful changes. Keep lab tests in continuous checks for fast regression signals, but do not report them as the field outcome.

Test yourself: Web Vitals

Five quick questions on the 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. initiative and what actually ranks. Pick an answer for each, then check.

Web Vitals

Web 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.

Related: Core Web Vitals

Web Vitals

Web Vitals is the umbrella initiative Google launched in May 2020 to give site owners a single, unified set of quality signals for delivering a great user experience on the web. It exists to cut through the noise of dozens of competing performance metrics by naming the ones that actually matter.

The program has two tiers. 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 the three metrics that apply to all pages, are surfaced across all Google tools, and feed Google’s ranking systems: 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. (Largest Contentful Paint, loading), INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. (Interaction to Next Paint, responsiveness — it 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), 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. (Cumulative Layout Shift, visual stability). Everything else under the initiative — 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., 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. — is a supplementary or diagnostic metric. They help you debug the Core metrics, but they are not ranking factors and their definitions can change more often.

Two distinctions matter most. “Web Vitals” and “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 not synonyms — Core is the ranking-relevant subset. And Google ranks on field dataPerformance metrics captured from real users, not lab tests. (real Chrome users in the 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. dataset, at the 75th percentile, page-level where available), not on lab scores from tools like 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.. A perfect lab score doesn’t mean your real users pass.

Related: Core Web Vitals

Changelog