Real User Monitoring: Understanding Website Speed in the Field and in the Lab

Real Users and Lab Tests

Real User Monitoring (RUM) tracks how a website performs during actual visits. A visit made on an older smartphone using a cellular connection can differ significantly from a visit on a desktop computer with a fast connection. The pages visited and user interactions are also factored into the overall picture.

A Lab Test In contrast, it examines a specific call under controlled conditions. The device type, network conditions, and test procedure can be specified for each analysis. This makes it easier to reproduce an anomaly and to test possible changes under comparable conditions.

These two perspectives address different questions: Field data can show that mobile product pages often load slowly. However, they do not prove whether, for example, the product image, the rendering path, or a slow document response is to blame. Identifying the root cause requires additional diagnostics and testable hypotheses.

PageSpeed Insights combines both perspectives: It compares available field data from the Chrome User Experience Report with lab diagnostics based on Lighthouse. The results may not match because real-world visits involve different conditions and usage patterns, whereas the lab examines a defined test case.

RUM therefore does not replace the lab. Conversely, a single lab test cannot show how often a problem occurs among actual visitors. Furthermore, prior to a launch or for a website with very little traffic, there may not be sufficient field data; without real visits, no RUM metrics are generated at all.

How RUM Measurements Are Generated

A custom measurement requires three components: data collection in the browser, a receiver for the transmitted values, and data analysis. First, you define which pages and visitor groups you want to analyze and how the data will be protected. Only when individual values are meaningfully aggregated can they serve as a basis for decision-making.

Browsers provide various performance interfaces for this purpose. Navigation Timing describes the timing of various aspects of navigating to the document, such as the response to the document request. Resource Timing provides timing information about individual loaded resources, such as images or scripts. This allows you to pinpoint different stages of the loading process more precisely.

A PerformanceObserver monitors supported performance metrics as soon as they become available. For Core Web Vitals, the library can web-vitals handle the calculation and reporting. The entries and metrics available depend, among other things, on the browser; therefore, a tracking script does not automatically capture every visit in its entirety.

Not every metric is generated immediately upon loading. For INP, for example, a specific interaction must occur: Someone who simply reads a page and then leaves may not contribute to that metric. A missing metric value is therefore neither zero nor evidence of a fast response.

A RUM service can provide tracking, collection, and analysis as a single package. If you develop your own solution, you’ll also need to organize operations, data storage, and quality assurance. This includes properly handling repeat requests throughout the page lifecycle, rather than counting each request as an independent visit without verification.

Reading Core Web Vitals correctly

The Core Web Vitals describe three different aspects of the user experience. Largest Contentful Paint (LCP) measures when the largest relevant content element becomes visible. On a product page, this could be a large product image, for example: If it appears late, the page may still seem like it hasn't finished loading, even though the navigation is visible early on.

Interaction to Next Paint (INP) measures the delay between user interactions and the next visible update. If a product filter takes a noticeable amount of time to respond after a click, INP can indicate this problem. Cumulative Layout Shift (CLS), on the other hand, describes unexpected shifts in visible content, such as when an element that appears later displaces a button.

For the PageSpeed Insights evaluation, an LCP of 2.5 seconds or less, an INP of 200 milliseconds or less, and a CLS of 0.1 or less are considered good. CLS is a dimensionless value. These thresholds apply to the respective metric and should not be confused with the duration of a single page view.

The key factor in the field evaluation is the 75th percentile (p75): At least about 75 percent of the data points considered do not exceed the respective value. A good average alone, however, can mask the fact that a significant portion of visits are slow. Consider mobile and desktop separately so that differences between the device groups remain visible.

Time to First Byte (TTFB) complements these metrics when investigating a slow document response. However, this value does not represent pure server processing time: the network and other stages involved until the first response byte arrives also play a role. Navigation Timing and, where available, Server Timing data help to examine the relevant sections in greater detail.

CrUX, its own RUM and lab

To get started, you don't have to run your own measurement system right away. PageSpeed Insights combines field data from the Chrome User Experience Report (CrUX) with a Lighthouse lab diagnosis. The two views answer different questions: One describes real-world experiences, while the other examines a page under controlled conditions.

The CrUX field data in PageSpeed Insights covers a 28-day historical window. If there isn't enough data for a specific URL, the report may display data for the origin instead. This data reflects the associated website origin and does not necessarily correspond to the user experience on the exact page you entered. Therefore, be sure to note which level the report is actually reporting on.

CrUX only includes Chrome users who meet the relevant requirements; other browsers and ineligible users are excluded. CrUX data may be missing for small or non-public websites. However, a custom data collection system—one that is legally and technically sound—can still provide insights in such cases, though it remains statistically limited when there are few visits.

Synthetic monitoring repeats predefined tests even when no one is currently visiting the website. It is useful for regularly observing a workflow under similar conditions. Whether users experience the same behavior on different devices or networks is a question that must be answered through field testing; a single synthetic test cannot replace this perspective.

When making a choice, the key factor is the question you want to answer: A public report is readily available, while your own system allows for more targeted data collection. A service can handle operational tasks, whereas laboratory and synthetic tests enable controlled investigations. However, even a service requires a deliberate selection of data and analysis groups.

Prepare Your Own Measurement Thoroughly

First, define a specific question—for example, whether mobile product pages are more likely to have a high LCP than other page types. Then determine which pages and device categories you want to distinguish, which metrics are needed for this, and how long you want to collect data. Only then should you decide on the tracking script, the destination, and the analysis.

As a first technical step, you can use the library web-vitals Integrate it locally into a browser project and view the output in the developer tools. The following JavaScript uses the published package version 6.2.3. It assumes that this version is installed in the project and that the build processes the module imports. The example does not send any data to a server and does not enable separate tracking of soft navigation.

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

onCLS(console.log);
onINP(console.log);
onLCP(console.log);

The console output is a way to test the integration; it is not an indication of your visitors' speed. Open the project page and interact with a filter, for example. An INP value requires a suitable interaction and may not appear immediately; without a suitable interaction, it may be missing entirely. Browser support and the page lifecycle also influence the output.

Plan to analyze the Page Lifecycle Note: Reports may be generated multiple times, for example, when a page is hidden and then displayed again later. Do not count these reports as separate visits across the board. The library provides metric IDs that can be used to associate reports with the same metric.

Restoring a document from the back/forward cache also requires specific handling. It can trigger a new metrics message, even though the document is being retrieved from the cache. Determine how you will distinguish such retrievals from ordinary navigation in your report, and review the specific library guidelines before setting up production-level tracking.

Analyze Measurement Data by Segment

An overall metric for the store can mask the fact that mobile product pages, in particular, are slower. Therefore, break down the metrics at least by page type and device category, and consider a specific time period for each metric. This way, for example, you can compare mobile product pages with mobile category pages, rather than inadvertently mixing different usage scenarios.

For each segment, the 75th percentile More meaningful than a simple average: It shows the value that at least about 75 percent of the data points do not exceed. A low average, on the other hand, can mask the fact that a relevant group is waiting a long time. Compare p75 values only for the same metric and using the appropriate unit.

The number of valid values is directly related to the result. If a segment consists of only a few measurements, individual data points can significantly influence the percentile; a change does not necessarily indicate a general problem. If necessary, select a longer time period or group together pages that are similar in nature without losing comparability.

A missing INP is not a fast INP and must not be included in the distribution as zero. Instead, specify the number of valid INP values separately. If many page views do not yield a suitable interaction, the INP analysis describes only the recorded interaction experiences and does not automatically cover all page views.

Properly group repeated reports based on the metric ID, rather than treating each response as a new, independent observation. Also, document how recoveries from the back/forward cache are counted. This ensures that it remains clear which observations are actually included in the p75 and in the specified count.

From the Field Problem to the Diagnosis

If the field data indicates slow mobile product pages, start by narrowing down the affected segment: Does the poor LCP affect many products or just one page type? At the same time, check the time period and the number of valid values. This will give you a starting point for your investigation, but it won’t yet provide proof of which element is causing the delay.

Then place it in the Lab Test Replicate conditions that are as similar as possible, such as using a mobile device configuration and limited network speed. Determine which element appears as the LCP and when it is loaded and rendered. A large product image, a late image request, or a blocked rendering path are possible hypotheses that you’ll need to test based on the diagnosis.

If there is any indication that images are being delivered, you can examine file sizes, formats, and delivery methods. A Content Delivery Network is a possible measure, but no guarantee of a better LCP. If, on the other hand, the document response indicates a bottleneck, an additional Server Benchmark for PHP Workloads, to examine the application under defined conditions.

With a delayed product filter, interaction is key rather than the loading process. Simulate a filter click and check what work is required before the update becomes visible. Where the browser supports it, you can Long Animation Frames They provide information about long rendering updates and the scripts involved; they do not automatically explain every slow interaction.

Implement a targeted change and then observe the same group of pages again in the field. A better lab result initially shows only the effect under the selected test conditions. Only the subsequent field evaluation can reveal whether the recorded experiences of real visitors have also changed.

Data Quality and Data Protection in Operations

Before going live, determine which metrics are necessary for your specific use case and who will process them. Planning should include secure transmission to the recipient, access restrictions, a limited retention period, and a deletion procedure. Review data protection and consent issues for the specific implementation and the applicable rules on a case-by-case basis, rather than assuming blanket approval.

With the Data minimization It’s worth taking a look at diagnostic fields: Full URLs may contain sensitive information in query parameters; DOM selectors can also reveal details about page content or user input. Whenever possible, capture a general page type and a few carefully selected attributes. Also check what additional information an integrated service collects or stores.

Metrics are not always available immediately. The web-vitals library may report metrics multiple times throughout the page's lifecycle; therefore, a later report should not automatically be counted as a new, independent visit. Plan how to handle related reports and how to handle restores from the back/forward cache.

For small diagnostic packages, data can be transferred via sendBeacon at the event visibilitychange be suitable. This improves the ability to trigger data transmission when a page is hidden, but does not guarantee delivery. The recipient must also securely accept the data and process it in such a way that repeated messages do not go unnoticed and skew the analysis.

Finally, take into account the Data Collection Gaps: Blocked scripts, lack of browser support, or lost sessions can result in certain visits being missed. Estimate the loss rate along with the type of data collection. The remaining metrics describe the observed group and may not represent all visitors equally.

Review Changes and Select a Procedure

To perform a comparison after a deployment, you must first specify which page types, device classes, and time periods to include. For each metric, compare the 75th percentile and the number of valid values before and after the change. Time frames of similar length help with context; however, this does not automatically result in sufficiently comparable samples.

Be aware of changes in the visitor mix. If, after a deployment, more users with slow mobile connections visit the site, the overall performance metric may worsen, even though the change itself isn't slower. Seasonal usage or other concurrent changes also make it difficult to pinpoint the cause. A temporal correlation is therefore a hypothesis, not a Proof of Causality.

CrUX and a site’s own RUM do not necessarily yield the same results: They may cover different user groups, time frames, and measurement conditions. In the case of CLS, CrUX also takes into account the contributions of embedded frames to the experience of the parent page. A JavaScript measurement in the main document does not always fully capture these contributions. Therefore, compare the measurement methodologies first before interpreting a discrepancy as an error.

In a single-page application, you should decide whether you want to analyze document navigation or internal route changes. For the separate tracking of Soft Navigation Starting with version 6, Web Vitals supports the option provided that the browser supports it reportSoftNavs: true. It must be set in the respective metrics callbacks. The previous console example without this option does not enable separate route measurement.

When soft navigation tracking is enabled, CLS and INP are reset for the new navigation and considered separately; the values from the previous navigation are finalized when the route changes. You should not compare such values—which are defined over different time periods—with document-wide metrics without first verifying them. Without appropriate browser support, this option will not result in a corresponding separate route measurement.

When choosing a RUM service, in addition to browser coverage, check whether the required page groups and device classes can be analyzed. Ask about sampling methods, data processing, retention, and export options. It’s equally important to consider what impact the tracking script itself might have on the page and whether its data collection can be limited to what’s necessary for your specific analysis.