At a glance
Comparison of origin-level vs per-URL field-data CWV measurements. Origin-level aggregates across all URLs for the domain; per-URL is specific to a single page. The two views answer different questions: origin tells you “what is the typical user experience across the whole site?”; per-URL tells you “what does the user experience on this specific page?” Per-URL data is critical for high-traffic pages (homepage, top PDPs) because they may have different CWV behaviour than the origin average. Per-URL data only available for URLs with sufficient real-user volume (~1,000+ sessions per 28 days).
Calculation
Calculated automatically from your Website Performance (PageSpeed + CrUX) data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A UK-based BigCommerce fashion store, mobile field data Wednesday 15 May 26.
What the origin-vs-URL view is telling us:
- Origin LCP at 4,820ms is dragged by the high-traffic homepage and PDP. Both contribute over 30 percent of mobile traffic and have LCP > 5,000ms. The homepage alone drives ~22 percent of the origin signal; fixing it lifts the origin metric significantly.
- Cart and checkout pages are dramatically better than origin on LCP. They’re 50-60 percent faster. Don’t optimise cart/checkout first; they’re already healthy. The optimisation targets are the high-traffic pages whose URL-level metrics are worse than origin.
- Per-URL diagnosis surfaces what origin hides. The collection page has the worst CLS (0.24); the PDP has the worst LCP (5,820ms); the homepage has the worst all-three failure pattern. Origin-level alone wouldn’t tell you any of this; you’d see “needs improvement” on all three CWV but not where to start.
-
The “all-3 pass” column is the launch-gate signal. Only checkout passes all three. The other URLs fail at least one. For pre-launch readiness gating (covered in
psi_all_cwv_pass), the per-URL view is essential, you can’t gate on origin-level when origin is partial passes mixed with full failures. -
Tail URLs (120+ pages) lack CrUX data. These are low-traffic product pages, edge URLs (about, contact, terms), legacy routes. Use lab data (
psi_slowest_lcp_urls) for per-URL diagnosis on these. CrUX simply doesn’t have enough samples to compute p75. -
Optimisation priority based on origin-vs-URL gap:
- Homepage (worst all-3 failure × 22% traffic) = highest-impact fix.
- PDP (worst LCP × 8% traffic) = high-impact fix; PDP template optimisation lifts ~78 PDPs.
- Collection (worst CLS × 12% traffic) = high-impact fix; collection template lifts 12 pages.
- Cart, checkout = healthy; protect from regression.
- Tail = low-priority; use lab data and template-level fixes.
- Origin recovery forecast: fixing the homepage + PDP template + collection template lifts the URL-level pass rates significantly. Origin pass rate (currently 64.8 percent) projects to ~78-82 percent post-fix because the high-traffic dragging URLs are now passing. The remaining 18-22 percent failing comes from tail URLs not addressed in this cycle.
- Compare origin vs URL. Identify URLs significantly worse than origin.
- Weight by traffic share. Worst-URL × highest-traffic = priority focus.
- Identify shared causes. When PDPs cluster at similar metrics, template-level fix is more efficient.
- Use lab data for tail URLs without CrUX coverage.
- Re-measure at 7-day rolling for early signal post-fix; full reflection at 28 days.
Sibling cards merchants should reference together
Reconciling against the vendor’s own dashboard
Where to look:- CrUX BigQuery dataset, query origin-level and URL-level data directly.
- PageSpeed Insights, paste an origin URL (e.g.
https://yoursite.com) for origin-level; paste a specific URL for per-URL. - Google Search Console → Core Web Vitals, surfaces URL groups with similar CWV behaviour.
Cross-connector reconciliation: primarily internal (with all per-CWV cards plus the per-URL lab ranking cards).
Quick rule for support tickets: if a merchant says “my origin LCP is fine but a specific URL shows nothing”, the URL doesn’t have enough traffic for CrUX URL-level p75. Use lab data via
psi_slowest_lcp_urls.
Known limitations / merchant FAQs
Why is my origin CWV worse than every individual URL I check? It’s a weighted aggregate. The origin number includes URLs you haven’t manually checked, including potentially many tail URLs with poor CWV that you don’t see when you spot-check the homepage and PDPs. Some URLs perform worse than the ones you naturally check. Should I optimise origin or specific URLs? Both, sequentially. Optimise high-traffic URLs first because they dominate the origin signal, fixing them lifts origin too. After high-traffic URLs are healthy, the origin metric should reflect their improvement. Tail URLs are addressed via template-level fixes that affect many pages at once. My homepage shows different CrUX data than the origin. Which is right for ranking? For ranking, Google uses URL-level CWV data when available; falls back to origin-level when URL-level isn’t. For the homepage (high traffic, definitely has URL-level data), Google uses the URL-level metric. For tail URLs, Google uses origin. Optimising the homepage URL-level matters most because that’s what Google sees for the homepage’s ranking. Can I get URL-level data for low-traffic pages? Not from CrUX. Use lab data via per-URL Lighthouse audits (psi_slowest_lcp_urls). The lab measurement isn’t the same as field but provides a useful proxy for engineering iteration on low-traffic pages.
Why does CrUX need 28 days of data per URL?
To produce a stable p75 from real-user variation. With fewer than ~1,000 sessions, the p75 is too noisy to be useful, single anomalous loads dominate the percentile. The 28-day rolling window ensures the metric is statistically stable.
My origin pass rate is failing but most individual URLs pass. What’s going on?
The minority of failing URLs is dragging the aggregate. Check traffic share: a URL with 1 percent traffic that’s failing badly can drag the origin pass rate down by 1 percent. If multiple URLs are partial-failing, the cumulative drag is larger. Identify the dragging URLs via the origin-vs-URL view and prioritise their fixes.
Can Vortex IQ tell me which specific URLs are dragging origin?
Yes; the worked example above shows the per-URL breakdown sorted by gap from origin. The Vortex Mind Pre-Launch Readiness report assembles this into a Kanban-ready action list.