Real User Monitoring Core Web Vitals from your own traffic, the next day and per page type, market and device
Real user monitoring measures the Core Web Vitals in your visitors' browsers and reports them to your own analysis. The Chrome User Experience Report, which Google uses for its assessment, averages over 28 days and shows a regression in full only after weeks. Real user monitoring shows it the next day, broken down by page type, market and device, and delivers the cause along with it. On platforms with weekly releases, it is the basis of any ongoing control.
Real user monitoring and the Chrome UX Report: same metrics, different sample
Both sources measure the same metrics with the same browser interfaces. They differ in whose visits they count, how quickly they report and how finely they can be segmented.
| Aspect | Chrome User Experience Report | Real user monitoring |
|---|---|---|
| Role | the benchmark Google assesses by | early warning and root-cause analysis |
| Browsers | Chrome only | all browsers that support the measurement interfaces |
| Period | rolling 28-day window | freely selectable, from one day |
| Segmentation | origin and individual URLs with enough traffic | page type, market, device, browser, release, consent |
| Causes | none | element, script and sub-parts per measurement |
| Gaps | pages with little traffic are missing | visitors without consent are missing, depending on the setup |
Which tools use which source is described under Measuring Core Web Vitals. Google documents the methodology of the Chrome User Experience Report under CrUX methodology.
Browser support in 2026: LCP and INP in Safari and Firefox, CLS only in Chromium
Until 2025, real user monitoring saw the Core Web Vitals practically only from Chromium browsers. That has changed:
- Safari: Since Safari 26.2 from December 12, 2025, the interfaces for Largest Contentful Paint and the Event Timing API, on which Interaction to Next Paint is based, are available.
- Firefox: Firefox has measured Largest Contentful Paint since early 2024. Firefox 144 from October 2025 added the grouping of events into interactions that Interaction to Next Paint requires.
- Cumulative Layout Shift: The Layout Instability API is so far available only in Chromium browsers. Cumulative Layout Shift therefore remains a Chrome and Edge metric in monitoring.
For the analysis, this means evaluating values separately per browser. The comparison with Google runs through the Chrome segment; the other browsers additionally show how visitors on iPhones actually fare. In markets with a high iOS share, that is often the larger group.
Dimensions of real user monitoring on enterprise platforms: page type, market, device and release
A single value for the whole domain is of little use in operations. Monitoring becomes useful only with attributes attached to every measurement:
- Page type: home page, category, product, article, search, form. The assignment comes from the platform's template, not from URL patterns that change with every campaign.
- Market and language: on multilingual platforms, content, tags and connections differ by country.
- Device and browser: mobile and desktop separately, plus the browser engine because of the differing support.
- Release: the version number of the deployment as an attribute. Only then can a regression be attributed to a deployment. How this feeds into sign-off after a release is described in AEM DevOps.
- Consent: whether the visitor agreed to tags. With consent, more scripts load, and the value for Interaction to Next Paint is then usually different.
The cause per measurement belongs with it. Google's web-vitals library delivers it in the attribution build: for Largest Contentful Paint, the element and the sub-parts from the server response to rendering; for Interaction to Next Paint, the element interacted with, input delay, processing duration and presentation delay, as well as the long animation frames with the scripts involved. This turns the message that a value has worsened into a statement of which script on which page type causes it.
Two biases belong in every analysis. First, visitors who did not consent to measurement are missing if the monitoring is tied to consent; the sample is then no longer representative of all visits. Second, many tools collect only part of the page views. Adobe Experience Manager, for example, collects one page view in a hundred by default through Operational Telemetry, as described under AEM Sites Optimizer.
Tools for real user monitoring: your own script, a specialized service or an APM platform
The offerings fall into three classes. Which one fits depends less on the feature set than on who reads the data in operations.
| Class | Examples | Strength | Limit |
|---|---|---|---|
| Own script | web-vitals library, sent to analytics or your own data warehouse | full control over attributes and data storage | analysis, alerts and maintenance remain with your own team |
| Specialized service | SpeedCurve, Akamai mPulse, RUMvision, DebugBear | ready-made analyses for Core Web Vitals, causes and comparison with lab data | an additional script on the page; check billing by data volume |
| APM platform with RUM module | Dynatrace, Datadog, New Relic | browser and server data in one view | Core Web Vitals are one view among many; analysis per page type is often custom-built |
If the organization already runs an APM platform, the shortest path usually lies there: the script is already on the page, and only attributes and analyses are missing. Without such a platform, a specialized service is usable faster than a custom build. For Adobe Experience Manager, there is also Operational Telemetry, which Sites Optimizer uses.
Alert thresholds in real user monitoring: 75th percentile per page type against the target value
Measurements become a control only once it is defined when a value triggers a response. A simple scheme works well:
- The 75th percentile is calculated per page type, market and device, as Google does for its assessment.
- Each page type has a target value with a margin below Google's threshold, for example 2.2 instead of 2.5 seconds for Largest Contentful Paint. The margin absorbs the spread before Google's field data tips over.
- If a value exceeds its target on two consecutive days, a ticket is created with the release in which the regression began and the causes from the attribution.
What such tickets look like is shown in the templates under Core Web Vitals acceptance criteria. How monitoring, target values and sign-off come together in a project is described under Website Performance Optimization. Delivery as the second source of high values is covered on the page CDN for enterprise platforms.
Book a free performance analysis
30 minutes via video call. You see your platform's Google user data and which attributes your monitoring lacks.
Frequently asked questions about real user monitoring
Does real user monitoring replace the Chrome User Experience Report?
No. Google assesses a website based on the Chrome User Experience Report, so that remains the benchmark. Real user monitoring adds daily data, page types with little traffic, other browsers and the causes behind a value. For comparison with Google, the Chrome segment of your own monitoring is what counts.
Why do monitoring values differ from Search Console?
Because the two sources count different visits. The Chrome User Experience Report covers only Chrome and averages over 28 days; real user monitoring, depending on the setup, covers other browsers, only visitors who gave consent and often only a sample. The figures become comparable when the monitoring is filtered to Chrome, the same device class and the same period.
Does real user monitoring also measure Safari and Firefox users?
For Largest Contentful Paint and Interaction to Next Paint, yes: Safari has supported the required interfaces since version 26.2 from December 2025, Firefox has measured Largest Contentful Paint since early 2024 and has supported the grouping of interactions since version 144 from October 2025. Cumulative Layout Shift is so far measured only by Chromium browsers.
How many measurements does a page type need?
Enough for the 75th percentile to stay stable from day to day. There is no fixed number; it depends on how widely the values spread. With a sample of one page view in a hundred, which AEM collects by default for Operational Telemetry, page types with little traffic often do not suffice for a daily evaluation, and the data is then aggregated over a week.