Core Web Vitals

Core Web Vitals are the three user-experience metrics — LCP, INP, and CLS — that Google measures from real Chrome users and folds into its page experience signals. Together they answer three questions about a page: how fast does the main content show up, how quickly does it respond when you touch it, and does it hold still while you read it.

The stakes are practical rather than dramatic. Core Web Vitals are a lightweight ranking input — they will not rescue thin content — but they are a hard gate for some SERP features, they show up as a dedicated report in Search Console, and they correlate strongly with bounce and conversion. When two pages are otherwise comparable, the one that loads clean tends to win. More to the point: fixing them almost always fixes things your users were already suffering through silently.

The three metrics side by side

Notice the third column of thresholds: a page has to clear all three at the "good" level to count as passing. One poor metric fails the URL.

Where the numbers actually come from

This is the part that trips up most site owners. The Core Web Vitals data Google uses for ranking comes from the Chrome User Experience Report (CrUX) — anonymized measurements collected from real Chrome users who opted into usage statistics. Three properties of that dataset matter for how you interpret your scores:

• 75th percentile. Your reported LCP is not the average — it's the value that 75% of real visits beat. A quarter of your users are having a worse experience than the number you see.
• 28-day rolling window. Ship a fix today and the field data catches up gradually over the following four weeks. Do not panic when Search Console still shows red two days after a deploy.
• Origin vs URL grouping. Low-traffic URLs get folded into origin-level or page-group data. If a specific URL has too little traffic, you're seeing a proxy, not that page.

Lab tools like Lighthouse simulate a single throttled load instead. That makes them great for debugging and useless for verifying what Google sees — the distinction is covered in depth in field data vs lab data.

A worked example: reading a PageSpeed Insights report

Run any URL through PageSpeed Insights and you get two blocks that people constantly conflate. The top block, "Discover what your real users are experiencing," is CrUX field data — the 28-day, 75th-percentile numbers with the pass/fail verdict. The bottom block, "Diagnose performance issues," is a fresh Lighthouse lab run on emulated hardware.

A typical audit finding: field LCP is 3.8 s (needs improvement) while lab LCP is 1.9 s. That mismatch usually means real users are on slower devices and networks than the lab emulates, or that a cookie banner, personalization script, or ad slot fires for real users but not for the lab robot. The field number is the one that counts; the lab run is where you go hunting for the cause.

If you want the raw field values from your own pages instead of Google's sampled ones, drop the web-vitals library in and ship the results to your analytics:

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

function send(metric) {
  navigator.sendBeacon('/vitals', JSON.stringify({
    name: metric.name,
    value: metric.value,
    id: metric.id,
    page: location.pathname
  }));
}

onLCP(send);
onINP(send);
onCLS(send);

This is called RUM (real user monitoring), and it beats CrUX in one crucial way: you can segment by page template, device, and country instead of staring at one blended number.

How to check Core Web Vitals on your own site

1. Search Console → Core Web Vitals report. Start here. It groups your URLs by status (poor / needs improvement / good) and by issue type, so you see which templates fail rather than which individual pages.
2. PageSpeed Insights for a representative URL from each failing group. Read the field block first, then use the lab diagnostics to find causes.
3. CrUX directly — via the CrUX API or the public BigQuery dataset — when you need origin-level history or competitor comparisons.
4. Chrome DevTools → Performance panel to reproduce the problem: record a page load with 4x CPU throttling and Slow 4G, then inspect the LCP marker, long tasks, and layout shift regions.
5. The web-vitals JS library (snippet above) for continuous field monitoring, or run a quick spot check with our Core Web Vitals checker.

Common mistakes in Core Web Vitals work

• Optimizing the Lighthouse score instead of the field data. The performance score is a lab composite; Google ranks on CrUX. I have watched teams celebrate a 98 Lighthouse score while their field INP sat at 600 ms because the lab never clicks anything.
• Fixing the homepage only. CrUX failures are almost always template-level. If product pages fail, fixing the homepage moves nothing in the Search Console report.
• Testing on a developer machine. An M-series laptop on office fiber is roughly 5–10x faster than the median phone in your field data. Always throttle.
• Declaring victory too early. The 28-day window means a fix shipped on the 1st doesn't fully show until the end of the month. Verify with RUM immediately, with CrUX later.
• Ignoring interaction between metrics. A late-loading hero image hurts LCP and shoves content down (CLS). Render-blocking scripts delay LCP and queue up main-thread work that wrecks INP. Fixes compound; so do problems.

Frequently asked questions

Are Core Web Vitals a big ranking factor?

No — they are a minor tiebreaker among page experience signals. Treat them as table stakes: bad vitals lose you users directly and rankings marginally. Good vitals will not outrank better content.

Which metric should I fix first?

Whichever one is red in Search Console for your highest-traffic template. If several are red, LCP first — its fixes (server response, image delivery, render-blocking cleanup) tend to improve the other two as a side effect.

Why does PageSpeed Insights show no field data for my page?

Not enough Chrome traffic on that URL in the last 28 days. You'll get origin-level data instead, or nothing. That's exactly the case where your own web-vitals RUM setup earns its keep.

Do Core Web Vitals apply on desktop and mobile?

Yes, evaluated separately. CrUX and Search Console report both. Mobile is almost always the harder one to pass and the one with more of your search traffic.

Did FID disappear?

Yes. INP replaced First Input Delay as the responsiveness vital in March 2024. FID only measured input delay on the first interaction; INP measures the full duration of the worst interaction across the visit, which is far harder to game. Full breakdown in our Core Web Vitals overview.