Measuring Core Web Vitals Which tool uses which source, and when which number applies
There are two kinds of numbers for the Core Web Vitals: field data from the behavior of real visitors and lab data from a simulated measurement. Almost every dispute about performance values arises because the two numbers are taken to be the same thing. This page maps the common tools to their source, names their limits and states which number applies in which situation.
Field versus labAs of August 2026
Field data and lab data measure two different things
Field data comes from real visits: with the device, the connection, the consent banner and the advertising tags the visitor actually has. Google collects it in the Chrome User Experience Report (CrUX) over a rolling 28-day window and bases its assessment on it. Lab data is produced in a controlled measurement on simulated hardware with a fixed network profile, without a tag manager and without consent.
In both cases, the same three metrics are assessed: Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift, complemented by Time to First Byte as a diagnostic value. Two rules follow from this. First: for acceptance, field data counts, because it is the benchmark. Second: for finding causes, lab data is the right tool, because it is reproducible and shows the waterfall, the main thread and individual elements. Agreeing on a lab measurement as the acceptance criterion leads to green reports and red user data.
PageSpeed Insights, Lighthouse, CrUX and other tools by data source
| Tool | Source | Strength | Limit |
|---|---|---|---|
| PageSpeed Insights | Field and lab | Shows both sources side by side, free, no account needed | One URL per run, no history |
| Lighthouse | Lab | Diagnosis with waterfall and main thread, can be automated | Score is mistaken for a target, no user data |
| Chrome User Experience Report | Field | The benchmark Google uses for its assessment, also for third-party domains | 28-day delay, only origins with enough measurements |
| Search Console | Field | Page groups and their development for your own domain | No causes, only affected URLs |
| WebPageTest | Lab | Real devices, real locations, very precise waterfalls | Complex to set up, hard to read for non-specialists |
| GTmetrix | Lab | Easy-to-understand presentation, history per test profile | Its own scoring logic, not Google's assessment |
| PerfDelta | Field and lab | Multiple pages and competitors, monitoring with alerts, performance budgets, prioritized fixes, APIs | The author's own tool, see disclosure below; projects and monitoring only in the paid plans |
| AEM Sites Optimizer | Field, as a sample from Operational Telemetry | Findings per page with suggestions, implementation after approval in the Ultimate tier | AEM only, only pages with 1,000 page views or more, separate license |
| Real User Monitoring | Field | Updated daily, per page type, market and device, all browsers | Own setup, costs, alignment with consent |
PerfDelta: monitoring, performance budgets and competitor comparison across multiple pages
Google's free tools answer the question for exactly one URL and then forget the result. For a platform, that is rarely enough: it consists of several page types, its values change with every release, and only a comparison with competitors shows whether a value is good. PerfDelta covers these three gaps. The measurements come from the same sources as in PageSpeed Insights: field data from the Chrome User Experience Report, lab data via the PageSpeed Insights API, each for mobile and desktop.
Report per measurement: field and lab data, page weight, third parties and diagnostics
Each report shows per page and device whether the Core Web Vitals are passed in the field, plus the field data of the entire domain for smartphones with history and trend. This is complemented by page weight by resource type, the largest third parties, optimization opportunities with estimated savings, and diagnostics: the LCP element, the elements that shift the layout, main thread work and the largest requests. The technology stack in use is detected, and the recommendations are tailored to the detected platform.
Prioritized fixes: first what fails a Core Web Vital in the field
Each measurement produces a list of actions in order of their impact. At the top is whatever affects a metric that fails for real users, each with the affected files, the estimated savings, and the affected pages and devices. In addition, it shows how often the same problem occurs on other measured websites and what effect was observed where it has been fixed.
Changes between two measurements: why a value has dropped
When a value drops, PerfDelta compares the current measurement with the previous one: page weight per resource type, new or heavier third parties and script bundles, a different LCP element, the segments of Largest Contentful Paint, server response time, new findings and the fixes implemented since. This makes it possible to attribute a regression to a release or a new tag instead of merely detecting it.
Projects, monitoring and competitors
In projects, the page types of a platform are measured together, with tags and groups, regularly and without manual effort. If a value deteriorates or a Core Web Vital fails, a notification is sent, plus a weekly report. Competitors are tracked via their field data from the Chrome User Experience Report, without additional measurements. Notes on a measurement, for example about a deploy, appear in the history next to the curve.
Performance budgets as a check in the delivery pipeline
Budgets apply to an entire project or a single page and cover page weight, JavaScript, images, fonts, third parties, number of requests, lab values and the field data of LCP, INP, CLS, FCP and TTFB. When a value comes within ten percent of its limit, PerfDelta issues a warning; when it is exceeded, the check fails. Optionally, a limit is lowered step by step toward a target value after 30 days without an overrun, so that a level once reached becomes the new upper limit. The result "passed" or "failed" can be integrated into a delivery pipeline via the REST API; an MCP server makes the same data available to AI assistants.
Disclosure: PerfDelta is Christian Schreiber's own tool. A single measurement with a public report is free; projects, monitoring, budgets and APIs are part of the paid plans with a monthly quota of measurements. It does not replace any of the Google sources but bundles them and adds comparison, history and control.
Measurement chain in operation: field data, real user monitoring and lab on three levels
Three levels together produce a reliable picture. First, field data as the benchmark, checked monthly against the thresholds, separately for mobile and desktop. Second, real user monitoring for daily updates, broken down by page type, market and device, so that a deterioration is noticed within 24 hours and not only after four weeks. Third, a lab measurement in the delivery pipeline that checks each page type against fixed limits and rejects a build that breaks them. PerfDelta's performance budgets cover this third level and add competitor comparison to the first.
Without the third level, the same cycle repeats: an optimization works, and two quarters later the gain has been used up by new tags and campaign components. How this chain is set up in a project is described under Website Performance Optimization.
Target values and ownership are not set by any measurement tool
No tool tells you which value should apply to which page group, who owns it and what happens if it is missed. That is exactly the task that comes before measuring: target values per page type, one owner per value and an acceptance process that takes place independently of the implementation. How many websites actually meet the thresholds is shown in the Core Web Vitals Benchmark.
Book a free performance analysis
30 minutes by video. You receive Google's real-user data for your platform compared with two competitors, regardless of whether we work together.
Frequently asked questions about measuring Core Web Vitals
Which tool is the right one for Core Web Vitals?
That depends on the question. For the assessment, field data counts: Chrome User Experience Report, Search Console or your own real user monitoring. For finding causes, lab measurements are the right tool: Lighthouse, WebPageTest and the diagnostic sections of PageSpeed Insights. Using a lab measurement for acceptance means measuring something other than what Google assesses.
Why does PageSpeed Insights show two different results?
Because it displays two sources. At the top is the field data from the Chrome User Experience Report, meaning the values of real visitors over the last 28 days. Below it is a Lighthouse measurement, which is generated on simulated hardware at the moment of the request. The score from 0 to 100 belongs to the lab measurement and is not part of any assessment by Google.
Why is field data missing for my page?
The Chrome User Experience Report only reports origins and page groups with sufficient measurements. With too little traffic, no values appear, sometimes only at origin level and not per page. Your own real user monitoring closes this gap, because it captures every session instead of only Chrome users who have enabled reporting.
Can PerfDelta stop a build when a performance budget is violated?
Yes. Performance budgets in PerfDelta return the result passed or failed for each measurement. Via the REST API, this result can be integrated into a delivery pipeline that rejects a build when the budget is violated. In addition to lab and weight values, budgets can also include the field data of LCP, INP and CLS.
What does PerfDelta measure that PageSpeed Insights does not show?
PageSpeed Insights assesses a single URL at the moment of the request. PerfDelta measures several pages of a platform regularly, places competitors alongside, reports deteriorations, checks performance budgets and uses the comparison of two measurements to explain why a value has dropped. In addition, there are prioritized fixes with affected files and estimated savings, detection of the technology stack and recommendations for the detected platform. The measurements themselves come from the same sources: field data from the Chrome User Experience Report, lab data via the PageSpeed Insights API. Disclosure: PerfDelta is Christian Schreiber's own tool, the single measurement is free.
How often should you measure?
Monitor field data daily, because the 28-day window smooths out changes anyway. Lab measurements belong in the delivery pipeline, meaning per release and per page type, with fixed limits. A manual measurement before go-live does not replace this: it misses exactly the regression that a new tag causes two weeks later.
Are Google's tools enough on their own?
For the assessment yes, for the work no. Search Console and the Chrome User Experience Report tell you whether a page group passes, but not which element tips the balance. That requires element-level diagnosis and a history across releases, which Google's tools do not keep.