[Digital Analytics](/categories/digital-analytics) October 26, 2026 # Core Web Vitals monitoring: track real users, not lab tests Monitor Core Web Vitals on real users: why lab scores and Search Console lag, how to measure LCP, INP and CLS by page and release, and when to alert. ![](/images/65d75b0ae8d69ef95785a5d6_david-pombar.webp) **[David Pombar](/author/david-pombar)** Swiss army knife at Trackingplan 5 min read · 1154 words > **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](https://developers.google.com/search/docs/appearance/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: 1. **Segment by page type.** Templates fail, not sites. Split by home, category, product, article and checkout so you see which template regressed. 2. **Segment by device.** Mobile INP and LCP are usually the problem; a desktop average hides it. 3. **Compare before and after each release.** A step change on the day of a deploy or a tag manager publish is your culprit. 4. **Watch the 75th percentile**, not the average, so your numbers match how Google rates the page. 5. **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](/docs/platform-metrics). The vitals behave like any other event in Trackingplan, so you can explore them in the [Data Explorer](/docs/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](/blog/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. On this page 1. [*01*The three metrics and their thresholds](#the-three-metrics-and-their-thresholds) 2. [*02*Lab data, field data and why the difference matters](#lab-data-field-data-and-why-the-difference-matters) 3. [*03*Why Search Console is not monitoring](#why-search-console-is-not-monitoring) 4. [*04*What real-user monitoring looks like](#what-real-user-monitoring-looks-like) 5. [*05*Third-party tags are part of the problem](#third-party-tags-are-part-of-the-problem) 6. [*06*Monitoring vitals with Trackingplan](#monitoring-vitals-with-trackingplan) 7. [*07*Frequently asked questions](#frequently-asked-questions) **Stop babysitting tags** Trackingplan audits your real user data around the clock and flags issues before they cost you. [Start free trial →](https://app.trackingplan.com/signup) ![](/images/65d75b0ae8d69ef95785a5d6_david-pombar.webp) **David Pombar** Swiss army knife at Trackingplan Read more from David, a Senior Product Strategist with 18+ years in digital product development and an atypical error detection knack. Share Copy link [LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.trackingplan.com%2Fblog%2Fcore-web-vitals-monitoring) [X](https://twitter.com/intent/tweet?url=https%3A%2F%2Fwww.trackingplan.com%2Fblog%2Fcore-web-vitals-monitoring&text=Core%20Web%20Vitals%20monitoring%3A%20track%20real%20users%2C%20not%20lab%20tests) Read next [All Blog →](/blog) - [ 8 minDigital AnalyticsOctober 20, 2026 ### AI analytics agents compared: what each one can see Six AI analytics tools compared by the evidence they read, how they work, and where they stop, for teams asking why GA4 and ad conversions dropped. by **Mariona Martí**](/blog/ai-analytics-agents-compared) - [ 16 minDigital AnalyticsOctober 14, 2026 ### GTM debugging: manual methods vs continuous monitoring How to debug Google Tag Manager with Preview Mode, extensions, the Network tab and server-side preview, and when continuous monitoring takes over. by **David Pombar**](/blog/gtm-debugging-guide) - [ 11 minDigital AnalyticsOctober 9, 2026 ### Meta Pixel and CAPI debugging tools compared Data Advisor, GTM Preview, DevTools, Test Events, Diagnostics, server logs, and Trackingplan: what each one proves when you debug Meta Pixel and CAPI. by **Mariona Martí**](/blog/meta-pixel-capi-debugging-tools) Trackingplan ## See everything. Miss nothing. Your implementations audited around the clock with real-time, real-user data. Real-time alerts about errors or changes in your data, campaigns, pixels, privacy and consent. Let AI flag issues before they cost you. [Start free trial →](https://app.trackingplan.com/signup) [Book a demo](/demo)