TL;DR Core Web Vitals are judged on real users, so monitor them on real users. Lab tests diagnose one page load; Search Console reports a 28-day average weeks after the fact. Monitoring means measuring LCP, INP and CLS on every visit, by page type, device and release, and getting a warning the day one of them moves, before it reaches Search Console.
Google's Core Web Vitals measure three things a visitor feels: how fast the main content appears, how quickly the page responds to a tap or click, and how much the layout jumps around. They are part of how Google evaluates page experience, and they are measured on real Chrome users, not in a lab.
That last point is why most teams monitor them the wrong way. They run PageSpeed Insights before a launch, look at Search Console once a month, and find out about a regression long after it shipped.
The three metrics and their thresholds
Google rates each metric at the 75th percentile of page loads: three out of four visits must be at or under the threshold for the page to count as good.
| Metric | What it measures | Good | Poor |
|---|---|---|---|
| LCP · Largest Contentful Paint | When the largest image or text block appears | ≤ 2.5 s | > 4 s |
| INP · Interaction to Next Paint | How long the page takes to respond to clicks, taps and keys | ≤ 200 ms | > 500 ms |
| CLS · Cumulative Layout Shift | How much visible content moves unexpectedly | ≤ 0.1 | > 0.25 |
INP replaced First Input Delay as a Core Web Vital in March 2024. Two supporting metrics help explain LCP: Time to First Byte (good at 800 ms or less) and First Contentful Paint.
Lab data, field data and why the difference matters
Lab data comes from a test: Lighthouse or the lab section of PageSpeed Insights loads one page once, on a simulated device and network. It is reproducible and shows what slowed that load down, which makes it the tool to diagnose and fix.
Field data comes from real visits, on real devices and connections. It is what Google uses. Google's public source for it is the Chrome UX Report (CrUX), which feeds the field section of PageSpeed Insights and the Core Web Vitals report in Search Console.
The two disagree all the time, for good reasons: your real visitors use slower phones than the simulation, arrive with a warm or cold cache, and interact with the page, which is the only way to measure INP at all. A page can score well in the lab and fail in the field.
Why Search Console is not monitoring
The Core Web Vitals report in Search Console is the score that matters, but it is a poor alarm:
- It is a 28-day rolling window. A regression that ships today takes weeks to show, and weeks more to clear after you fix it.
- It groups URLs. It reports groups of similar pages, so you see that a group is failing, not which change caused it.
- It needs traffic. Pages and sites without enough Chrome visits have no field data at all.
- It is Chrome only, and only users who share usage statistics.
Use it to confirm where you stand. Do not use it to find out that something broke.
What real-user monitoring looks like
Real-user monitoring (RUM) measures the vitals in the browser of every visitor and sends them with the rest of your data. Google's open-source web-vitals JavaScript library is the standard way to collect them. With that data you can:
- Segment by page type. Templates fail, not sites. Split by home, category, product, article and checkout so you see which template regressed.
- Segment by device. Mobile INP and LCP are usually the problem; a desktop average hides it.
- Compare before and after each release. A step change on the day of a deploy or a tag manager publish is your culprit.
- Watch the 75th percentile, not the average, so your numbers match how Google rates the page.
- Alert on change, not only on thresholds. A move from 1.8 to 2.4 seconds is still "good" and is still a regression worth catching.
Third-party tags are part of the problem
Every pixel, tag manager container, consent banner and chat widget runs in the same browser as your page. They compete for the main thread and the network, which is how a marketing release can damage INP or LCP without a single line of product code changing. A consent banner that loads late and pushes content down shows up as CLS.
So when vitals regress, check what changed in your tags as well as in your code. The two are rarely released by the same team, which is why the regression often goes unexplained.
Monitoring vitals with Trackingplan
Trackingplan collects web vitals from your real visitors alongside your analytics and marketing traffic. Platform > Vitals shows LCP, FCP, TTFB, INP, FID and CLS, together with traffic and JavaScript errors, and warns you about unexpected changes. The vitals behave like any other event in Trackingplan, so you can explore them in the Data Explorer.
That puts a performance regression and the rest of your tracking in the same tool: the day LCP moves, you can check whether a tag, a consent change or a JavaScript error appeared at the same time. Monitoring the data your marketing runs on, where it is collected, is what we call marketing observability.
Search Console tells you whether your pages pass. Real-user monitoring tells you when they stop passing, while there is still time to fix it.
Frequently asked questions
What is Core Web Vitals monitoring?
Measuring Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift continuously on the visits your site actually gets, and getting told when they get worse. It is different from a one-off PageSpeed test, which measures one page load in a lab.
What are the Core Web Vitals thresholds?
Google rates a page good when, at the 75th percentile of page loads, Largest Contentful Paint is 2.5 seconds or less, Interaction to Next Paint is 200 milliseconds or less, and Cumulative Layout Shift is 0.1 or less. Above 4 seconds, 500 milliseconds and 0.25 respectively it is poor.
Why does Search Console show Core Web Vitals problems so late?
Because its Core Web Vitals report uses Chrome UX Report data, which is aggregated over the previous 28 days. A regression that ships today needs weeks to move the report, and pages with little traffic may not have enough data to appear at all.
Is PageSpeed Insights enough to monitor Core Web Vitals?
No. It is the right tool to diagnose one page, because its lab test shows what slows that load down. It is not monitoring: it tests a single load on demand, and its field data is the same 28-day Chrome UX Report data Search Console uses.