Web Vitals

Web Vitals: definition and why it matters

Web Vitals is Google's umbrella program of real-world performance metrics for measuring page experience. It's broader than Core Web Vitals alone: Core Web Vitals (LCP, INP, CLS) are the three headline metrics Google actually uses as a ranking signal, while the wider Web Vitals set also includes supporting diagnostics like TTFB, FCP, and TBT that help you explain why a Core metric is failing.

The stakes: only the three Core metrics feed the page-experience signal, but you can't fix them without the supporting ones. A page that fails LCP because of a slow server won't improve until you look at TTFB. Treating Web Vitals as one flat list of "speed scores" is how teams burn a sprint optimizing the wrong thing.

This page is the wide-angle map of the whole metric family. For the deep dive on the three ranking metrics and their exact thresholds, go to the Core Web Vitals entry and the 2026 CWV overview. We won't repeat those thresholds in depth here.

The full Web Vitals family, in one table

Rule of thumb: the Core three are what Google scores you on; TTFB, FCP, and TBT are the levers you pull to move them.

Measuring it in the browser with the web-vitals library

Google ships a tiny open-source JavaScript library called web-vitals that reports the exact same values Chrome sends to CrUX. Drop it into your real pages and send the numbers to your analytics so you're measuring actual users, not a lab test from a datacenter in Iowa.

import {onLCP, onINP, onCLS, onTTFB, onFCP} from 'web-vitals';

function sendToAnalytics({name, value, id}) {
  // Beacon survives page unload; use it for INP/CLS which finalize late.
  navigator.sendBeacon('/vitals', JSON.stringify({name, value, id}));
}

onLCP(sendToAnalytics);
onINP(sendToAnalytics);
onCLS(sendToAnalytics);
onTTFB(sendToAnalytics);   // supporting: explains slow LCP
onFCP(sendToAnalytics);    // supporting: server vs render bottleneck

Once this is live, you can slice results by device, template, and country instead of arguing over a single Lighthouse score. That distinction between what real users see (field) and what a test rig sees (lab) is the whole game; the field vs lab data guide walks through when each one lies to you.

How to check Web Vitals on your own site

1. Start with field data in Search Console. Open the Core Web Vitals report. It groups real URLs into Good / Needs Improvement / Poor using CrUX. This is the source of truth for ranking, because it's what real Chrome users experienced.
2. Confirm with PageSpeed Insights. Run a slow URL through a page speed analyzer or PageSpeed Insights. The top of the report is field (CrUX) data; the bottom is a lab run you can debug against.
3. Reproduce in Lighthouse locally. Open Chrome DevTools, throttle to "Slow 4G / 4x CPU," and run Lighthouse. Now you can profile the exact resources hurting LCP or the scripts inflating TBT.
4. Instrument real users. Add the web-vitals library above so you catch regressions between deploys instead of waiting 28 days for CrUX to update.
5. Segment by template. Group results by page type (product, article, listing). One bad template usually drags a whole property down.

Common mistakes and how to fix them

• Optimizing the lab score, ignoring field data. A green Lighthouse score means nothing if CrUX shows real users on Poor. Fix: always start from Search Console field data, then use lab to debug.
• Treating TBT and INP as the same number. TBT is a lab proxy; INP is measured on real interactions. A page can have low TBT and still fail INP if a late click triggers heavy work. Fix: test real interactions, not just page load.
• Chasing a "100" score. The thresholds are pass/fail bands, not a leaderboard. Once LCP is under the "Good" bar, moving from 2.1s to 1.9s buys you nothing for ranking. Fix: get every Core metric into Good, then stop.
• Blaming the front end for a TTFB problem. If TTFB is 1.5s, no amount of image optimization saves LCP. Fix: check server response and caching first when TTFB is high.
• Measuring one URL and calling it done. CrUX reports at the origin and URL-group level. Fix: sample multiple URLs per template before you conclude anything.

FAQ

Is Web Vitals a ranking factor?

Only the three Core Web Vitals (LCP, INP, CLS) feed Google's page-experience signal. The supporting metrics (TTFB, FCP, TBT) are diagnostics; Google does not rank on them directly. They matter because they explain and drive the Core three.

What's the difference between Web Vitals and Core Web Vitals?

Core Web Vitals is the subset Google uses for ranking. Web Vitals is the larger set that also includes supporting metrics. Every Core Web Vital is a Web Vital; not every Web Vital is Core. See the Core Web Vitals entry for the thresholds.

Why don't my Lighthouse and Search Console numbers match?

Lighthouse is a single lab test on simulated hardware; Search Console shows 28 days of real users across every device and connection they used. They will rarely match. Trust field data for ranking decisions and use lab data to debug. The field vs lab breakdown covers this in detail.

How long until fixes show up in Search Console?

CrUX uses a rolling 28-day window, so a fix takes weeks to fully reflect. Watch your real-user instrumentation (the web-vitals library) for immediate confirmation, then wait on Search Console for the official verdict.

Does INP replace FID?

Yes. Interaction to Next Paint replaced First Input Delay as the responsiveness Core Web Vital in 2024. INP looks at all interactions across the page's life, not just the first one, which makes it far harder to game.