Frontend Performance

CrUX URL-Level vs Origin-Level Data: Which Number Describes Your Page?

This guide clarifies how field data is aggregated, as part of Understanding Core Web Vitals Thresholds in Core Web Vitals & Measurement. The Chrome User Experience Report (CrUX) publishes Core Web Vitals at two granularities: for individual URLs, and for whole origins. They answer different questions, and confusing them is the root of many "we fixed the page but nothing changed" stories.

URL-level data exists only when a URL receives enough eligible Chrome traffic in the 28-day collection window. Most URLs on most sites do not. When a URL lacks its own data, tools fall back: PageSpeed Insights shows origin data; Search Console assigns the URL to a group of similar URLs and reports the group's status. Either way, the number you see may describe thousands of other pages.

Which CrUX number are you looking at? Decision sequence showing when a URL has its own CrUX data, when tools fall back to origin data, and when Search Console uses URL groups. Which CrUX number are you looking at? URL has enough eligible traffic in 28 days? URL-level p75 — describes this page yes no Viewing in Search Console? URL group status — similar pages pooled yes no Origin has enough traffic? Origin-level p75 — the whole site yes no No field data — rely on your own RUM and lab tests

Rapid Diagnosis: What Is Your Tool Actually Showing?

  • PageSpeed Insights labels the field section either "This URL" or "Origin" in its toggle. If the URL toggle is unavailable, the page has no URL-level data.
  • CrUX API: a records:queryRecord request with url returns a 404-style NOT_FOUND error when the URL lacks data; the same request with origin returns site-wide data.
  • Search Console Core Web Vitals report shows URL groups with an "example URL" and a group-level status. Clicking through shows similar URLs — they share a status, not individual values.
  • CrUX BigQuery is origin-level only (monthly tables); it never contains per-URL data.
  • CrUX History API provides weekly time series for both URLs and origins, for the last several months, where data exists.

Root Cause Analysis: Why the Two Disagree

1. Traffic weighting. Origin-level p75 is computed over all page loads across the origin. High-traffic templates dominate it. A slow, rarely visited admin page barely moves the origin; a slow homepage moves it a lot.

2. Eligibility thresholds. CrUX requires a minimum volume of eligible samples for a URL to be published, to protect privacy and ensure statistical stability. Low-traffic pages — individual articles, product variants — often never qualify.

3. URL normalisation. CrUX strips fragments and normalises some aspects of the URL, but query parameters may create distinct URLs. Campaign parameters (?utm_source=…) can split traffic across URL variants, preventing any variant from reaching eligibility.

4. Grouping by similarity in Search Console. Search Console groups URLs it judges similar (often by template) and assigns the group's aggregated status to each member. A single slow URL in a group is invisible; a fast page in a slow group is reported as slow.

Origin p75 LCP as a traffic-weighted blend Bar chart of p75 LCP for four templates alongside their share of traffic, showing the origin value is dominated by the highest-traffic template. Origin p75 LCP as a traffic-weighted blend Product pages (55% of loads) 2.9s Category pages (25%) 2.1s Articles (15%) 1.7s Checkout (5%) 3.6s Origin p75 (blend) 2.7s 2.5s

Step-by-Step: Using Each Level Correctly

1. Check whether the URL has its own data

bash
curl -s "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=$CRUX_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"url":"https://example.com/products/trail-shoe","formFactor":"PHONE",
       "metrics":["largest_contentful_paint","interaction_to_next_paint"]}' | jq '.record.metrics'
# trade-off: the API key is rate-limited; batch historic queries through the
# History API instead of polling queryRecord in a loop.

Expected outcome: either URL-level metrics, or an error telling you to look elsewhere. Do not interpret origin numbers as describing this page.

2. Use origin data for site-wide trends, not page diagnosis

Origin-level p75 is the right number for executive dashboards and for whether "the site" passes, because it reflects what a typical page load experiences. It is the wrong number for prioritising which template to fix. For that, you need template-level data from your own RUM or URL-level CrUX for your top pages.

3. Map Search Console groups to templates

Export the URLs Search Console lists in each group and map them to your templates. Groups usually correspond to a template; when a group mixes templates, its status is a blend and should be investigated in RUM.

javascript
// Map example URLs from a Search Console export to route templates.
const templates = [[/^\/products\/[^/]+\/?$/, 'product'], [/^\/c\//, 'category'], [/^\/blog\//, 'article']];
const toTemplate = (url) => templates.find(([re]) => re.test(new URL(url).pathname))?.[1] ?? 'other';
const counts = exportedUrls.reduce((m, u) => (m[toTemplate(u)] = (m[toTemplate(u)] || 0) + 1, m), {});
console.table(counts);
// trade-off: regex template mapping drifts when routes change. Prefer emitting
// the template name from the server (a meta tag) and reading it in RUM.

Expected outcome: each failing group becomes "the product template on mobile", which is something a team owns.

4. Fill the gaps with your own RUM

For pages without URL-level CrUX, your RUM is the only per-page field data. Make sure it captures the template and URL so you can produce the per-page view CrUX cannot.

Which data source answers which question Mapping of common Core Web Vitals questions to the data source best suited to answer each. Which data source answers which question Question Best source Why Does the site pass overall? CrUX origin the assessed site-wide view Does this top page pass? CrUX URL its own 28-day p75 Which template fails? Your RUM per-template p75 Did yesterday's deploy help? Your RUM daily, not 28-day Why does group X fail? RUM + lab groups pool many URLs

Verification

After a fix, verify at the level where it should show up. A template-wide fix should appear in your RUM template p75 within days, in URL-level CrUX for that template's top pages within 28 days, in the Search Console group after Google re-validates (use "Validate fix"), and in origin data in proportion to that template's share of traffic. If origin data does not move, check the traffic weighting before concluding the fix failed: improving a template with 5% of loads cannot move origin p75 far.

Practical Implications for Prioritisation

The weighting has a direct consequence: to move origin-level status, fix the templates with the most traffic first, even if they are not the slowest. A checkout page at 3.6s with 5% of traffic is a real problem for revenue, but fixing it will barely move origin p75; a product template at 2.9s with 55% of traffic will. Conversely, to improve a specific high-value URL's search visibility, its own URL-level data — if it has any — is what matters. Keep both lists and be explicit with stakeholders about which goal each piece of work serves.

Reading the CrUX History API for Trend Analysis

The 28-day rolling window makes CrUX slow to react, and looking at a single snapshot after a release tells you little. The History API returns weekly data points for roughly the last six months, for both URLs and origins, which lets you see trends and the gradual effect of a fix as old data ages out.

bash
curl -s "https://chromeuxreport.googleapis.com/v1/records:queryHistoryRecord?key=$CRUX_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"origin":"https://example.com","formFactor":"PHONE","metrics":["largest_contentful_paint"]}' \
  | jq '.record.metrics.largest_contentful_paint.percentilesTimeseries.p75s'
# trade-off: each weekly point is still a 28-day aggregate, so consecutive
# points overlap heavily. A step change in your RUM appears as a ramp here
# that takes about four weekly points to complete.

When reading the series, expect a fix shipped on a given date to produce a ramp over the following four weeks, not a step. A regression appears the same way in reverse. If the ramp starts before your release date, something else changed — a traffic shift, a third-party update, a CDN configuration — and your release may be getting credit or blame it does not deserve.

Plot URL-level and origin-level series together for your top pages. When a top page's URL series improves but the origin series does not, the page's share of traffic is too small to move the origin; when the origin improves but the top page does not, the improvement came from other templates. Both are normal, and both are frequently misread as a measurement problem.

FAQ

Why does PageSpeed Insights show different field data from Search Console for the same URL?

They may be showing different levels. PSI shows URL-level data when it exists, else origin. Search Console shows the URL's group status. If the URL has no URL-level data, PSI's origin number and Search Console's group number are aggregations over different sets of pages, so they can legitimately disagree.

Do query parameters split CrUX data?

They can. URLs differing only in query parameters may be treated as distinct, which divides traffic and can stop each variant reaching the eligibility threshold. Canonical URLs do not change how CrUX aggregates. Keep campaign parameters off internal links, and do not use query parameters for content that should be one page.