> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # Site-wide vs Page Performance, Website Performance (PageSpeed + CrUX) > Site-wide vs Page Performance for Website Performance (PageSpeed + CrUX) stores. Tracked live in Vortex IQ Nerve Centre. How to read it, why it matters, an... **Metrics type:** [Supporting Metrics](/nerve-centre/overview#metrics-types-explained) • **Category:** [Website Performance](/nerve-centre/connectors#connectors-by-type) ## 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`](/nerve-centre/kpi-cards/website-performance/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 | What the origin-vs-URL view is telling us: 1. **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. 2. **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. 3. **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. 4. **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`](/nerve-centre/kpi-cards/website-performance/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. 5. **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`](/nerve-centre/kpi-cards/website-performance/slowest-lcp-urls)) for per-URL diagnosis on these. CrUX simply doesn't have enough samples to compute p75. 6. **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. 7. **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. The diagnostic flow: 1. **Compare origin vs URL.** Identify URLs significantly worse than origin. 2. **Weight by traffic share.** Worst-URL × highest-traffic = priority focus. 3. **Identify shared causes.** When PDPs cluster at similar metrics, template-level fix is more efficient. 4. **Use lab data for tail URLs** without CrUX coverage. 5. **Re-measure at 7-day rolling** for early signal post-fix; full reflection at 28 days. Rapid-response playbook: | 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`](/nerve-centre/kpi-cards/website-performance/page-load-speed) | Origin-level LCP. | | [`crux_inp_p75`](/nerve-centre/kpi-cards/website-performance/click-responsiveness) | Origin-level INP. | | [`crux_cls_p75`](/nerve-centre/kpi-cards/website-performance/layout-stability) | Origin-level CLS. | | [`psi_slowest_lcp_urls`](/nerve-centre/kpi-cards/website-performance/slowest-lcp-urls) | Lab per-URL ranking; the lab fallback for low-traffic URLs. | | [`psi_worst_cls_urls`](/nerve-centre/kpi-cards/website-performance/worst-cls-urls) | Lab per-URL CLS ranking. | | [`psi_worst_inp_urls`](/nerve-centre/kpi-cards/website-performance/worst-inp-urls) | Lab per-URL INP ranking. | | [`psi_all_cwv_pass`](/nerve-centre/kpi-cards/website-performance/all-cwv-pass) | Per-URL all-three CWV pass status. | | [`psi_cwv_pass_rate`](/nerve-centre/kpi-cards/website-performance/speed-test-pass-rate) | Origin-level pass rate. | | [GSC `gsc_mobile_usable_pages`](/nerve-centre/google_search_console/gsc_mobile_usable_pages) | GSC's URL-grouped CWV view. | ## Reconciling against the vendor's own dashboard **Where to look:** * **[CrUX BigQuery dataset](https://github.com/GoogleChrome/CrUX#crux-on-bigquery)**, query origin-level and URL-level data directly. * **[PageSpeed Insights](https://pagespeed.web.dev)**, 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](https://search.google.com/search-console)**, surfaces URL groups with similar CWV behaviour. **Why per-URL data may be missing in Vortex IQ:** | 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`](/nerve-centre/kpi-cards/website-performance/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. | **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`](/nerve-centre/kpi-cards/website-performance/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`](/nerve-centre/kpi-cards/website-performance/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. *** ### Tracked live in Vortex IQ Nerve Centre *Site-wide vs Page Performance* is one of hundreds of KPI pulses Vortex IQ tracks across Website Performance (PageSpeed + CrUX) and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. [Start for free](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.