Core Web Vitals monitoring: a four-layer setup for LCP, INP and CLS that accounts for the 28-day lag (2026)

Page speed work tends to become a "finished job" once it is done. Yet when you look again a few months later, the numbers have often slipped back. A new banner, an analytics tag, campaign images, a change to the cookie banner all add up little by little. Nobody set out to slow the site down, so nobody knows when it got worse.

This article sets out how to monitor Core Web Vitals (Google's three page experience metrics) continuously. Rather than how to optimise, it puts one question at the centre of the design: "how many days until someone notices it got worse, and who?" Monitoring search and traffic numbers is covered in "Search Console and GA4 monitoring automation", and uptime monitoring and updates in "Website maintenance automation". Here the focus is page speed only.

Main sources for this article: web.dev's explanations of each Core Web Vitals metric, the CrUX (Chrome UX Report) methodology and API documentation on Chrome for Developers, Google Search Central and Search Console Help, the official Lighthouse and Lighthouse CI documentation, and the HTTP Archive Web Almanac 2025, all checked on 27 October 2026.

1. What has changed: two years in which the metrics and tools were replaced

Between 2024 and 2026, both the Core Web Vitals metrics and the tools around them changed. If monitoring set up a few years ago is still running untouched, it may be watching a metric that no longer exists, or a tool that has been retired.

INP replaced FID, and FID has gone from the tools

On 12 March 2024, the responsiveness metric changed from FID (First Input Delay) to INP (Interaction to Next Paint). FID looked only at the delay before the first interaction. INP looks at every interaction while the page is open and reports close to the slowest one. Search Console dropped FID on the day of the switch, and PageSpeed Insights and CrUX removed it after a six-month deprecation period.

The CrUX Dashboard has ended, replaced by CrUX Vis

Google announced that the CrUX Dashboard, which showed monthly CrUX data in Looker Studio, would be retired after the end of November 2025, with CrUX Vis as its successor. If you had embedded it in a report, check that you are not left with empty charts.

Field data is due to be removed from the PageSpeed Insights API

The getting-started page for the PageSpeed Insights API (PSI API) states that Google plans to stop including real-user data (field data) in its results, and recommends the CrUX API and CrUX History API instead. It is safer to move now to taking real-user data from the CrUX API.

Only about half of sites pass on mobile

In the HTTP Archive Web Almanac 2025 (CrUX data from July 2025), sites with all three metrics rated good were 48% on mobile and 56% on desktop. Mobile was 36% in 2023 and 44% in 2024, so it is slowly rising. By metric, the one that fails most often on mobile is LCP (62% good).

INP is good on 97% of sites on desktop, so the problem is almost entirely on mobile. Making mobile the primary focus of your monitoring is the sensible default.

2. The three metrics: definitions and thresholds

Before building monitoring, agree on what is being measured. All three are loosely called "speed", but they measure different things.

All three are assessed at the 75th percentile of real users (the experience of the slowest quarter), with mobile and desktop judged separately.

LCP: look at it in four parts

LCP (Largest Contentful Paint) is the time until the largest image or block of text in the viewport is rendered. web.dev splits LCP into four subparts and suggests as a guide time to first byte (TTFB) at about 40%, resource load delay under 10%, resource load duration at about 40% and element render delay under 10%. Which part grew tells you whether a regression is a server problem or an image problem.

INP: the slowest interaction, ignoring outliers

INP is the time from a click, tap or key press until the next visual change is painted. Scrolling and hovering are not counted. One highest interaction is ignored for every 50 interactions, and the slowest remaining one is reported, so on pages with few interactions it is effectively the slowest one. Because it needs real interactions, Lighthouse cannot measure it and uses TBT (total time the main thread was blocked) as a proxy.

CLS: the largest burst of shifts

CLS (Cumulative Layout Shift) is how much elements move unexpectedly. Shifts less than one second apart, within a window of at most five seconds, are grouped into one burst, and the largest burst is reported. Shifts within 500 milliseconds of user input are excluded. Lab tests only watch the load, so shifts that happen further down the page after scrolling only appear in real-user data.

3. Field data versus lab data

Page speed numbers come in two kinds: field data collected from real users and lab data measured by a machine under fixed conditions. The most common confusion in monitoring is comparing the two as if they were the same thing.

Monitoring does not work with only one of them. Field data is right but slow; lab data is fast but does not match real users.

Main reasons the numbers disagree

According to web.dev, lab tests measure a first visit with a cold cache, while real users include many repeat visitors whose pages load quickly from cache or the bfcache (back/forward cache). Conversely, on logged-in pages or in A/B tests, the element that counts as LCP can itself change.

The score is not a pass mark

Since Lighthouse 10, the performance score (0–100) is a weighted blend of TBT 30%, LCP 25%, CLS 25%, FCP 10% and Speed Index 10%. 90–100 is green, 50–89 orange and 0–49 red. It is separate from the Core Web Vitals assessment and does not include INP.

4. Where field data comes from: CrUX, Search Console and your own RUM

There are three main routes to real-user data. All reflect real experiences, but they differ in who collects it, how granular it is and how late it arrives.

CrUX (Chrome UX Report)

CrUX is collected from Chrome users who have usage statistics reporting and browsing history sync turned on. It covers desktop Chrome and Chrome on Android, and does not include Chrome or Safari on iPhone, or other browsers such as Edge. Only pages that are public and have a minimum number of visitors are included; the exact threshold is not published.

There are several ways to get at CrUX.

For automation you will mainly use the CrUX API and CrUX History API. Both need a Google Cloud API key and the quota cannot be raised by paying, but for a few dozen key pages it will not be a constraint.

The Search Console Core Web Vitals report

The Search Console Core Web Vitals report is also based on CrUX. Its distinctive features are that it shows "URL groups" of pages with similar experiences, and that a group's status follows its worst metric. Groups without enough data fall back to the origin's values. After a fix, "Validate fix" starts a 28-day check that the issue has gone.

It is slow and coarse as an early-warning tool, so use it as a shared screen everyone can look at, and make detailed decisions from the API numbers.

Your own RUM (the web-vitals library)

RUM (Real User Monitoring) means collecting real-user experiences yourself with a measurement script. Google's web-vitals library is about 3KB compressed and returns values through onLCP, onINP and onCLS. The attribution build, about 1.5KB larger, also tells you which element was the LCP and which interaction was slow.

Send the data in batches with navigator.sendBeacon() when the page becomes hidden (visibilitychange). LCP and INP can be measured in Chromium, Firefox and Safari; CLS only in Chromium. The advantage is that you can fill in Safari experiences that CrUX does not show.

5. The 28-day rolling window: improvements and regressions both show up late

CrUX values are an aggregate of the previous 28 days of real-user experiences. Without knowing this, you get "we fixed it but the number hasn't moved" and "we noticed the regression three weeks later".

Seven days after a fix, three quarters of the window is still pre-fix experience. Because the 75th percentile is set by the whole aggregate, even a large improvement often crosses a threshold only two to three weeks later. Regressions work the same way.

As the table shows, the 28-day aggregate is a tool for confirming, not for noticing. Leave the noticing to lab data and RUM.

Do not mistake the weekly overlap for change

The CrUX History API returns a 28-day aggregate every week as one period, so neighbouring periods overlap by three weeks. Read it in two steps: spot early signs in the week-on-week change, and confirm with the change on four weeks ago, when the window has fully turned over. That reduces misreadings.

6. How to automate: build it in four layers

Given these properties, it makes sense to build monitoring from four layers that work at different speeds. Fast layers notice; slow layers confirm.

Small sites are often fine with layers 1 to 3. Add layer 4 when there is the will, and a person, to keep improving.

Layer 1: regression check on deploy

This is the most cost-effective layer. Add Lighthouse CI (the automated way to run Lighthouse) to your deployment pipeline, for example in GitHub Actions, measure the staging site five times and block the release when the median exceeds the budget.

Layer 2: daily record of lab values

Use the PSI API to test key pages at a fixed time every day and store the results in a spreadsheet or database. If you do not specify strategy, the PSI API tests as desktop, so always add strategy=MOBILE. Changes that never go through a deploy, such as tags added in a tag manager or images replaced in the CMS, are only caught in this layer.

Layer 3: weekly check of real-user data

Every week, take the mobile and desktop 75th percentile for key page groups and the whole origin from the CrUX History API. The update lands around 04:00 UTC on Mondays, so run it from Monday midday. You can look back up to 40 periods (about nine months).

7. Setting budgets and assertions in Lighthouse CI

Depending on its settings, Lighthouse CI tends to end up either failing every time until nobody looks, or blocking nothing.

How many runs, and which value to judge

Lighthouse CI runs three times by default, but the Lighthouse documentation says the median of five runs is about twice as stable as one run. Judge on the median. The documentation recommends a dedicated machine with at least two cores, and advises against shared-core instances and function-as-a-service platforms.

Example configuration

The following example runs five times under mobile conditions and judges on the median. The numbers are DevNJ starting values; adjust them to your site's current state.

{
  "ci": {
    "collect": { "numberOfRuns": 5, "url": ["https://staging.example.com/"] },
    "assert": {
      "assertions": {
        "largest-contentful-paint": ["error", { "maxNumericValue": 3000, "aggregationMethod": "median" }],
        "cumulative-layout-shift": ["error", { "maxNumericValue": 0.1, "aggregationMethod": "median" }],
        "total-blocking-time": ["warn", { "maxNumericValue": 300, "aggregationMethod": "median" }]
      }
    },
    "upload": { "target": "filesystem" }
  }
}

Size budgets go in the same block, written as resource-summary:script:size and so on (in bytes). Lab conditions are often harsher than real users', so start with a "no worse than today" budget and lower it as things improve.

error versus warn

Assertions have three levels: off (not checked), warn (reported, does not block) and error (blocks). Block on LCP and CLS, and not much else. If everything is an error, urgent fixes get blocked too and eventually the checks are switched off altogether. Among the upload targets, temporary public storage, which deletes reports after a few days, is somewhere anyone can view, so save results for unreleased pages to the filesystem or your own LHCI server.

8. Alert thresholds: decide the conditions first

The biggest reason monitoring fizzles out is too many alerts. Lab values vary from run to run, so decide the alert conditions for each layer in advance.

The numbers are DevNJ starting values. Record without alerting for the first three weeks, then set the conditions from the actual spread; that cuts false alarms.

Use both relative and absolute conditions

LCP going from 1.0 to 1.2 seconds is a 20% regression but feels almost the same, while 2.4 to 2.7 seconds is only 12% yet crosses the threshold. Alert when both the relative and absolute conditions are met, or when a category boundary is crossed. Including links to the deploy history and the tag manager's publish history in each alert makes the cause easier to narrow down.

9. Numbers to watch weekly, and numbers to ignore

The point of automating is to reduce the numbers people have to look at.

Look at around five page groups such as home, listings, detail pages, articles and contact, not individual pages. In the Web Almanac 2025, the pass rate for home pages (45% on mobile) was lower than for secondary pages (56%), while INP was worse on secondary pages (69% good on mobile), so watching only the home page misreads the site.

10. Typical causes of regressions: images, tags, fonts and cookie banners

The routes by which page speed gets worse are surprisingly predictable.

The right-hand column is the clue. Worse with no deploy points to the tag manager or ads; every page worse evenly points to fonts or a shared component.

Images: dimensions and lazy-loaded LCP images

In the Web Almanac 2025, 62% of mobile pages had at least one image without explicit dimensions (width and height), which causes CLS. Around 16% also lazy-loaded their LCP image (loading="lazy"). CMS themes that add lazy loading to every image indiscriminately are a common culprit.

Ad and analytics tags

In the Web Almanac 2025, over 90% of pages loaded at least one third-party service, and the median number of third-party requests was 79 on mobile. Ad and analytics scripts use the same main thread as user interactions, so they directly worsen INP.

Tag managers: changes that skip the deploy

Tags added in a tag manager bypass the layer 1 deploy check. Logging the publish dates in the same sheet as the layer 2 daily measurements lets you match them against the day things got worse.

Web fonts: Japanese fonts are especially heavy

While a font loads, text rendering is delayed and LCP grows; when it swaps in, CLS appears. web.dev recommends font-display: optional for body text, swap for headings, and size-adjust to match the fallback font's size. A single Japanese typeface can run to several megabytes, so subsetting or using system fonts makes a real difference. On bilingual sites, simply not loading the Japanese font on English pages can improve things.

Cookie banners: the weight comes after consent

web.dev calls cookie banners a very common source of layout shifts. Inserted at the top of the screen, they push content down, and on mobile the banner itself can become the LCP element. Then, right after "Accept", third-party scripts load all at once and INP suffers. The remedies are to load the banner script asynchronously and directly in the HTML, and to show it as a sticky footer or a modal.

11. Cost ranges: from free combinations to paid RUM

Costs depend on how many layers you automate. These are DevNJ estimates, not statistics. Yen figures use €1 = ¥175 and an outsourced hourly rate of €80.

Tiers 1 and 2 cost almost nothing a month because the tools are free. The CrUX API and CrUX History API are free, and GitHub Actions is free on standard runners for public repositories, with 2,000 minutes a month included in the free plan for private ones. Some services, such as Cloudflare Web Analytics, collect Core Web Vitals for free and say they use no cookies.

Paid RUM in tier 3 is usually priced by page views and the number of lab tests; as an example, SpeedCurve listed plans from $90 a month as of 27 October 2026. When comparing, get quotes for the same number of page views and check where the data is stored.

12. Japan and Europe compared: same metrics, different assumptions

The Core Web Vitals thresholds are the same worldwide, but the assumptions behind monitoring differ between Japan and Europe. For sites with users in both, keep the following in mind.

In Japan, sending user information to an external service through a RUM script may require notice or publication under the external transmission rules. In Europe, whether consent is needed depends on whether the RUM uses cookies or device identifiers; the Dutch Data Protection Authority (Autoriteit Persoonsgegevens, AP) says limited analytics with little privacy impact may not require consent. With paid RUM, always check whether it uses cookies and where the data is stored.

CrUX does not include iPhone users, so pages with many iPhone visitors are exactly where filling in Safari values with RUM makes sense.

13. Worked examples (two fictional companies)

The following are fictional companies used to show how monitoring might be set up. They are not real businesses.

Company A: an online shop selling Japanese groceries in the Netherlands

About 30,000 visits a month, 70% on mobile. Products change daily in the CMS, and the agency releases code once a month. It uses a cookie banner, a review widget and ad tracking tags. At this size tier 2 fits. With few releases, what helps most is not layer 1 but the layer 2 daily tests and layer 4 RUM. It watches INP for the product-list filter and INP after cookie consent separately in RUM.

Company B: a Japanese manufacturer's English site for Europe

About 2,000 visits a month, so CrUX only shows origin-level values. It updates a few times a year. Tier 1 is enough: the PSI API records mobile lab values for five key pages daily, and the CrUX History API tracks the origin weekly. It serves Europe from a server in Japan, so if TTFB is more than half of LCP, adding a CDN will do more than monitoring.

Both narrow the first numbers to watch to one or two.

14. Common mistakes and what not to do

Monitoring that did not help tends to fail in the same ways.

The first two are the most common. When reporting a number, always state which device it is for and whether it is lab or field data.

The other failure is finding problems with nobody and no deadline assigned to fix them. Decide, at the same time as the monitoring, who receives an alert and within how many days they ask whom to fix it. The thinking behind pre-release checks is also covered in "Automated blog publishing needs a quality gate".

15. Steps to get started (four weeks)

Rather than building all four layers at once, the approach least likely to fail is to start by recording, and add alerts later.

1. Week 1: decide what to watch. Split the site into about five page groups and pick one to three representative URLs for each. Write down the current mobile 75th percentile for all three metrics
2. Week 1: prepare API keys. In Google Cloud, enable the PageSpeed Insights API and the Chrome UX Report API and issue a key restricted to them
3. Week 2: start the daily and weekly records. With a scheduler such as GitHub Actions, call the PSI API (strategy=MOBILE) every day and the CrUX History API every Monday, appending results to a sheet. Send no alerts yet
4. Week 3: add the regression check on deploy. Run Lighthouse CI five times against staging and judge on the median. Start with LCP and CLS as warnings to see the spread
5. Week 4: set thresholds and alerts. Check the spread from three weeks of records, adjust the conditions from section 8 and switch alerts on. Raise LCP and CLS to errors
6. From week 4: add RUM if needed. If there are page groups you will keep improving, add the web-vitals attribution build and decide where data goes, how long it is kept and how consent is handled
7. Every quarter: review the monitoring itself. Check for changes to metrics or tools (section 1), whether alerts were useful, and whether any are being ignored

16. Checklist

A list to use at set-up and at each quarterly review.

• Split the site into about five page groups and chose representative URLs
• Decided to judge pass or fail on field data (CrUX 75th percentile)
• Added strategy=MOBILE to PSI API calls
• Taking real-user data from the CrUX API / CrUX History API
• Lighthouse CI runs five times and judges on the median
• Limited blocking errors to roughly LCP and CLS
• Alert conditions include both relative and absolute changes
• Recording the tag manager's publish history
• Confirmed the LCP image is not lazy-loaded
• Not loading Japanese fonts on English pages
• The cookie banner does not push content down
• Decided where RUM data goes, where it is stored and how consent is handled
• Decided who acts on an alert, and within how many days they ask whom

17. Summary

• Core Web Vitals pass at the real-user 75th percentile with LCP ≤ 2.5 s, INP ≤ 200 ms and CLS ≤ 0.1, assessed separately for mobile and desktop
• The PSI score is not a pass mark. Use lab data to find causes and catch regressions, and field data for pass or fail
• CrUX is a 28-day rolling aggregate, so improvements and regressions show up one to three weeks late. Leave the noticing to lab data and RUM
• Build monitoring in four layers: deploy, daily, weekly and always-on; small sites manage with layers 1 to 3
• Tools change. Check the move to INP, the end of the CrUX Dashboard and the PSI API's handling of field data
• Regressions mostly come from images, ad tags, tag managers, web fonts and cookie banners
• Each week, watch only the three mobile metrics with week-on-week and four-week change. Set alerts after three weeks of recording

Sources

Metric definitions (web.dev, W3C)

• Web Vitals — web.dev: thresholds and the 75th percentile
• Interaction to Next Paint (INP) — web.dev: definition of INP
• INP becomes a Core Web Vital on March 12 — web.dev: date of the switch
• Largest Contentful Paint (LCP) — web.dev: definition of LCP
• Optimize Largest Contentful Paint — web.dev: the four LCP subparts
• Cumulative Layout Shift (CLS) — web.dev: definition of CLS
• Why lab and field data can be different — web.dev: lab versus field
• Best practices for cookie notices — web.dev: cookie banner impact
• Best practices for fonts — web.dev: font fixes
• Event Timing API — W3C: the specification behind INP

CrUX (Chrome for Developers)

• CrUX methodology — Chrome for Developers: eligibility
• CrUX API — Chrome for Developers: updates and quota
• CrUX History API — Chrome for Developers: weekly 28-day aggregates
• CrUX on BigQuery — Chrome for Developers: monthly data
• CrUX Dashboard deprecation — Chrome for Developers: retirement

Google Search, PageSpeed Insights and Lighthouse

• Understanding Core Web Vitals and Google search results — Google Search Central: relationship with Search
• Core Web Vitals report — Search Console Help: URL groups and validation
• About PageSpeed Insights — Google for Developers: lab conditions
• Get started with the PageSpeed Insights API — Google for Developers: plans for field data
• runPagespeed — PageSpeed Insights API Reference: default strategy
• Lighthouse performance scoring — Chrome for Developers: score weights
• Lighthouse variability — GoogleChrome/lighthouse: median of five runs
• Lighthouse CI configuration — GoogleChrome/lighthouse-ci: assertions and upload targets
• web-vitals — GoogleChrome: size and sending data

Statistics (HTTP Archive)

• Performance — Web Almanac 2025: pass rates and images
• Third Parties — Web Almanac 2025: third-party services

Costs and rules

• GitHub Actions billing — GitHub Docs: free minutes
• Cloudflare Web Analytics: free collection
• SpeedCurve Pricing: example paid RUM pricing
• External transmission rules (外部送信規律) — Ministry of Internal Affairs and Communications, Japan: notice and publication requirements

All sources were checked on 27 October 2026. Metrics, tools and prices change, so check the official sites for current information before you set anything up. Costs, effort and starting thresholds are DevNJ working estimates and vary with the size and structure of the site.