Methodology: how PerfDelta measures Core Web Vitals and page speed

Last updated: October 9, 2026. Author: Christian Schreiber.

This page explains where every number in a report comes from, under which conditions it is measured and where the measurement reaches its limits. To run a test, use the page speed test. What each metric means and how to improve it is explained in the Core Web Vitals guide.

Data sources: PageSpeed Insights, CrUX and CrUX history

A report combines three public Google APIs. They differ in whether they describe a single page or the whole domain, which devices they cover and which period they span. Most differences between the sections of a report come from exactly that.

Which pages are measured

The URL you enter is always the first page. PerfDelta then reads the sitemap declared in robots.txt, or tries /sitemap.xml and /sitemap_index.xml, and picks structurally different pages: URLs are grouped by their first path segment and one page is taken from each group in turn. A free test covers three pages. You can also name the additional pages yourself; they have to be on the same domain. If a domain was tested before, the same set of pages is measured again so that results stay comparable over time. If the site blocks the sitemap request or has no sitemap, only the homepage is measured and the report says so.

Every page is measured twice, once with the mobile and once with the desktop profile of the PageSpeed Insights API. Both results appear side by side in the report.

Field data from the Chrome UX Report per page and device

Field data comes from the Chrome UX Report (CrUX), the dataset Google collects from Chrome users who opted in. PerfDelta shows the 75th percentile of Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift; it also reads First Contentful Paint and Time to First Byte. The 75th percentile means that three quarters of page views were at least as fast as the value shown. CrUX covers a rolling 28-day window and only exists for pages with enough Chrome traffic.

If a single URL has no data, the report falls back to the data of the whole domain and marks it as “origin-level data”. If the domain has no data either, the report says “No field data available”. This often happens for one device type only: a site with little mobile traffic then has desktop values but no mobile ones. Across all devices combined the domain often still has enough traffic, which is why the competitor comparison can show values while the mobile column of the field data table stays empty.

Lab data from Lighthouse and its test conditions

Lab data comes from a single Lighthouse run through the PageSpeed Insights API (performance category). It includes Largest Contentful Paint, First Contentful Paint, Cumulative Layout Shift, Total Blocking Time, Speed Index, Time to Interactive and server response time, as well as the page weight by resource type and the third-party scripts with the most main-thread time.

Lighthouse measures under fixed, simulated conditions, so the values describe a reference device rather than any particular visitor:

Throttling is simulated (Lighthouse's default “simulate” method) while the page itself loads on Google's infrastructure. The values are taken from the Lighthouse configuration in the project's public source code. A single lab run can vary between measurements; field data is the more stable signal.

Field data and lab data differ for three reasons

Reading the sections of a report side by side, you will often find different values for the same metric. They come down to three differences between the data sources:

• Device type: the field data table separates mobile and desktop. The competitor comparison and the CrUX trend combine all devices.
• Level: the field data table shows the single page where possible. The competitor comparison and the CrUX trend always describe the whole domain.
• Time window: the competitor comparison uses the latest daily dataset. The last point of the CrUX trend ends with the last completed week and is therefore a few days older.

An example from a report on October 2, 2026: the homepage of an agency website had a desktop LCP of 1557 ms. The competitor comparison showed 1500 ms for the whole domain across all devices, the CrUX trend 1412 ms for the last week. All three values are correct; they answer different questions.

Between field and lab there is a fourth difference: Lighthouse measures a single page load on a reference device, while field data combines real visits on very different devices and connections. A good lab value does not guarantee good field data, and vice versa.

Thresholds and the pass rule

These are Google's Core Web Vitals thresholds. A page passes when all three values are in the good range. A metric that CrUX does not report for a page, for example INP on a page with too few interactions, does not count against it. A page without any field data does not pass. “x of y pages pass” counts per device type over the pages that have field data.

Lab values are rated with the Lighthouse thresholds, among them First Contentful Paint 1.8 s / 3.0 s, Total Blocking Time 200 ms / 600 ms and Speed Index 3.4 s / 5.8 s (good / poor).

Competitor comparison with CrUX domain values

Competitor domains are not tested in the lab. For them PerfDelta queries the CrUX API for the whole origin and shows the 75th percentile of LCP, INP and CLS, aggregated across all device types. Your own domain appears in the first row with the same kind of value, so the comparison is like for like. If the domain without “www.” returns no data, the version with “www.” is queried, since CrUX treats both as separate origins.

The number of competitors depends on the plan: two in the free test, three on Solo, five on Agency and ten on Scale.

Reference rows complete the table:

• PerfDelta median: the median of the CrUX domain values of all domains PerfDelta has measured successfully so far, using the most recent test of each domain. Until October 2026 this row showed the mean, which a single outlier could shift noticeably. The number in parentheses is how many domains are included. It describes the sites tested with PerfDelta, not the web as a whole.
• Platform median: the same value for the domains on the platform detected for your site (for example WordPress or Shopify), from the website speed statistics. It appears only for platforms with at least 30 domains.
• Industry median (Agency and above): the same value for the domains of your industry. It appears only once at least 30 domains of that industry are included. Without the industry benchmark the report shows only your position in the industry (best quarter, typical, slowest quarter), without the values.

Below the table the report states your position: the share of measured websites whose value is worse than yours, per metric, among all domains and among the domains of your platform. It is interpolated from 21 points of the distribution (every fifth percentile) and shown between 1 and 99 percent.

A second table shows the field data from phones only, because Google uses them for mobile search, for your domain and your competitors. The trend compares the latest weekly value with the value twelve weeks earlier; changes under five percent count as stable. These values come from the same cached CrUX queries as the free Core Web Vitals benchmark.

CrUX trend: weekly 28-day windows over six months

The CrUX trend comes from the CrUX History API and shows the domain across all devices combined. Each point is its own 28-day window that closes at the end of that week. Neighboring points therefore overlap to a large extent, and the line responds to a change on the site slowly and smoothly. Google currently provides about 25 weeks, roughly six months.

The color of each point shows how that week rates against the thresholds above: green for good, amber for needs improvement, red for poor. The green dashed line marks the boundary to “good” and is always within view. The red dashed line for “poor” appears once the values reach it. Without these lines the automatically scaled axis would make small variations of good values look like large swings.

The value at the top right of each card is the latest weekly value. It can differ slightly from the competitor comparison, which uses the latest daily dataset.

Global, industry and platform benchmarks

The global comparison value is the share of websites that pass all three Core Web Vitals: 48 percent on mobile and 56 percent on desktop, according to the HTTP Archive Web Almanac 2025 based on CrUX data (as of November 2025). Pass rates from PerfDelta's own measurements are in the website speed statistics. Pass rates by CMS and platform from the same source are collected in the Core Web Vitals benchmark.

For the industry benchmarks each measured domain is assigned to one of 18 industries: first from schema.org and Open Graph markup, then from a language-model classification of the page content (title, description, headings and a short text excerpt), and only as a last resort from the technology stack. Domains from PerfDelta’s curated measurement lists that this classification cannot assign keep the industry noted in the list; in a comparison, list and model agreed for nine out of ten domains. The assignment is an estimate and is refreshed every 30 days or when the content changes. Per industry, the most recent test of each domain is used; PerfDelta calculates the pass rate, the average mobile lab score and the 25th, 50th and 75th percentile of every metric, once a day, with one stored value per month for the history. An industry page appears only once at least 30 domains are included. Example measurements are shown without domain names. The platform comparison (for example by CMS) follows the same rules.

Optimization notes and AI analysis

The recommendations in a report come from the Lighthouse opportunities with a potential saving of at least 100 ms, the longest phase of the Largest Contentful Paint on the page with the slowest LCP, the third-party services and script bundles with the most main-thread time or unused code, long script execution as a lab proxy for Interaction to Next Paint, and the elements that cause layout shifts. Where Lighthouse reports only bytes, the saving is converted into time at the throughput of a slow 4G connection and marked as an estimate. The figure next to each title says what it measures: an estimated saving, unused bytes, main-thread time, blocking time, the duration of an LCP phase or the CLS value.

The order follows the field data first: actions that affect a Core Web Vital failing for real users come first, then the larger potential saving.

The texts come from the PerfDelta recommendation library: curated texts for every type of finding, with variants for platforms such as WordPress and Shopify. Missing variants for a platform or a third-party service are written by a language model and stored in the library, where they can be reviewed; the next report with the same finding uses the stored text. The model receives only the type of finding, the detected platform and the name of the service, no URLs or measured values, and it does not add figures. Figures, files, pages and devices always come from the measurement. The models are provided by Mistral AI and, for texts written in the background, OVHcloud AI Endpoints. The industry classification uses Mistral AI.

Comparison values under an action come from PerfDelta's own data: how often the finding occurs on the measured websites and the typical saving there. Where an action from one measurement no longer appears in the next measurement of the same pages, PerfDelta records the change of the related lab metric (LCP, Total Blocking Time for INP, CLS). From ten such observations the report shows the median change. This is an observation, not proof of cause, since other changes can happen between two measurements.

When a measurement has a predecessor with stored page data, the report and the monitoring alerts list what changed between the two: page weight by resource type, new or heavier third-party services and script bundles, a different LCP element, LCP phases, server response time and new findings.

The technology stack is detected from the HTML and headers of the homepage using the open signatures of the webappanalyzer project; scripts and the rendered page are not evaluated.

Monitoring, monthly budget and repeated measurements

A free test is a single measurement. Reports stay available for 365 days and are then deleted. Without an account a domain can be re-measured at most once every 60 minutes. A free account allows one scan per day of up to three pages.

On the paid plans PerfDelta measures the URLs of a project automatically, using exactly the method described on this page. It runs on a monthly budget of PageSpeed tests. Each test is one Lighthouse run for one URL on one device, so a URL on mobile and desktop costs two. Monitoring, manual scans in the web app, scans via MCP and, from Agency, via the REST API all draw on the same budget.

You set interval and device (mobile, desktop or both) per project. If the budget does not cover every setting, each monitored URL first gets a weekly test, then URLs are upgraded to their chosen interval in the order they were added. Whatever no longer fits is measured less often, and the project page shows this per URL. Weekly tests are spread across the days of the week so they do not all run on the same day.

Monitoring comes first: a manual scan, including via MCP or the API, only starts if it leaves enough for monitoring until the end of the month. Manual scans also have a daily cap of one fifth of the monthly budget. The budget resets on the first of the month.

If a monitored URL gets noticeably worse or better, the account owner receives an email. An optional weekly report summarizes how a project developed; it only reads stored measurements and triggers no extra tests. PerfDelta fetches the field data of every monitored URL daily straight from the CrUX API, including URLs that are lab-tested less often; it costs no PageSpeed test, and Google updates CrUX once a day.

Known limits

• CrUX data trails reality by up to 28 days; a fix shows up in field data only gradually.
• Lab values come from a single run and can differ from one test to the next.
• If a site blocks Google's test agent, Lighthouse measures the error page; the report shows the HTTP status.
• Sites with bot management sometimes block PerfDelta's requests for the sitemap and the homepage as well. PerfDelta then measures only the URL you entered, or the technology stack stays empty.
• For domains with little Chrome traffic CrUX returns no or only partial field data. The competitor comparison and the CrUX trend then stay empty.
• The CrUX history in the report reaches back about six months, which is the limit of Google's API.

If you have questions about the method, I'm happy to answer them via the contact form.

Frequently asked questions about the method

Why does PageSpeed Insights show different values than PerfDelta?

PerfDelta queries the same PageSpeed Insights API. Differences come from the natural variation between Lighthouse runs and from field data shifting daily with its 28-day window. Two requests at different times rarely return identical numbers.

Why is there no mobile field data when the domain has values?

CrUX only reports values when enough Chrome users visited a page. For a single device type the traffic is often too small, while the whole domain across all devices still qualifies. The competitor comparison shows that domain value.

Why does the Lighthouse score change with every test?

Lighthouse simulates a device and a connection but runs on real hardware in a Google data center. Server load, network and third-party scripts change from run to run. Variations of a few points are normal.

How quickly does an improvement show up in field data?

Field data covers the last 28 days, so an improvement appears gradually and is fully visible after about four weeks. The CrUX trend lets you follow it week by week.

Which counts for Google rankings, field data or lab data?

Google uses the field data from the Chrome UX Report for Core Web Vitals as a ranking signal. Lab data explains why a page is slow but does not feed into rankings directly.