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).
| What it counts | Side-by-side comparison of LCP p75, INP p75, CLS p75 at: (a) origin level (whole-site aggregate), (b) per-URL level (specific page). The card identifies URLs where origin and URL-level metrics diverge significantly, surfacing pages that need separate optimisation focus. |
| Sample type | Field data sourced from CrUX. Both origin-level and URL-level come from the same dataset. |
| Why origin and URL can diverge | (1) High-traffic URLs dominate origin: if the homepage drives 30 percent of traffic with poor LCP, the origin LCP is dragged toward the homepage. (2) Template variation: PDPs may have different CWV behaviour than collection pages or homepage. (3) Tail URLs differ from head: if 100 product pages have varying performance, the origin averages across them while per-URL surfaces the worst. |
| When to use origin-level | Site-wide diagnostic: “is the brand passing CWV for ranking purposes?” Google’s ranking signal works at origin level; the origin pass rate is what matters for SEO. Use origin-level for: ranking-impact decisions, executive reporting, monthly trend analysis. |
| When to use URL-level | Page-specific diagnostic: “is this specific page performing well?” Per-URL surfaces targeted optimisation opportunities and identifies which URLs are dragging the origin average. Use URL-level for: engineering iteration, identifying which pages to fix first, validating page-specific deploys. |
| The “URL-level not available” pattern | CrUX requires sufficient traffic per URL (~1,000+ sessions per 28-day window per device) to compute URL-level p75. Tail pages with low traffic show origin-level only; per-URL is null. This is structural, not a bug. The lab-data alternative (psi_slowest_lcp_urls) provides per-URL synthetic measurements when CrUX URL-level isn’t available. |
| Currency | n/a, comparison view with metric values. |
| Time window | 28D (CrUX-fixed). |
| Alert trigger | URL-level metric > 25 percent worse than origin (suggests a high-traffic URL is structurally different from the average and needs separate attention). |
| Sentiment key | null (multi-value comparison view). |
| Roles | owner, operations |
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.| Scope | LCP p75 | INP p75 | CLS p75 | All-3 pass | Notes |
|---|---|---|---|---|---|
| Origin (whole site) | 4,820ms | 520ms | 0.170 | 64.8% | Headline aggregate |
/ (homepage, 22% traffic) | 5,140ms | 380ms | 0.21 | 0% (fails all) | Worse than origin on LCP + CLS |
/products/spring-floral-maxi-dress (8% traffic) | 5,820ms | 220ms | 0.18 | 0% | Worst LCP on the site |
/collections/new-arrivals (12% traffic) | 4,610ms | 480ms | 0.24 | 0% | Worst CLS on the site |
/cart (8% traffic) | 2,180ms | 220ms | 0.04 | passes LCP+CLS, fails INP | Better than origin on most CWV |
/checkout (4% traffic) | 1,940ms | 180ms | 0.04 | passes all three | Best per-URL performance |
| URLs with insufficient CrUX volume | n/a | n/a | n/a | (lab-data fallback) | ~120 tail URLs |
- 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.
| Time horizon | Action |
|---|---|
| First 1 hour | Identify URLs with biggest origin-vs-URL gap. |
| First 24 hours | Plan template-level fixes for the worst-performing high-traffic templates. |
| First 7 days | Ship fixes; field metrics start moving. |
| Day 28 | Field per-URL metrics fully reflect; re-evaluate. |
Sibling cards merchants should reference together
| Card | Why merchants reach for it |
|---|---|
crux_lcp_p75 | Origin-level LCP. |
crux_inp_p75 | Origin-level INP. |
crux_cls_p75 | Origin-level CLS. |
psi_slowest_lcp_urls | Lab per-URL ranking; the lab fallback for low-traffic URLs. |
psi_worst_cls_urls | Lab per-URL CLS ranking. |
psi_worst_inp_urls | Lab per-URL INP ranking. |
psi_all_cwv_pass | Per-URL all-three CWV pass status. |
psi_cwv_pass_rate | Origin-level pass rate. |
GSC gsc_mobile_usable_pages | GSC’s URL-grouped CWV view. |
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.
| Reason | What to do |
|---|---|
| Insufficient traffic. CrUX requires ~1,000+ sessions per 28-day window per device. | Use lab data from psi_slowest_lcp_urls. |
| Recently launched URL. New URLs need 28+ days to accumulate CrUX data. | Wait or use lab. |
| Auth-gated URL. CrUX only samples public URLs that opted-in users browse. | Lab is the only option. |
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.