> ## 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. # Speed Test Pass Rate, Website Performance (PageSpeed + CrUX) > Speed Test Pass Rate for Website Performance (PageSpeed + CrUX) stores. Tracked live in Vortex IQ Nerve Centre. How to read it, why it matters, and how to ... **Metrics type:** [Supporting Metrics](/nerve-centre/overview#metrics-types-explained) • **Category:** [Website Performance](/nerve-centre/connectors#connectors-by-type) ## At a glance > The percentage of real-user page-loads where **all three Core Web Vitals (LCP, INP, CLS)** met Google's "good" thresholds. **The single field-data number that decides whether Google considers the site to be passing CWV** for ranking purposes. A site at 75 percent or above has Google's algorithm classifying it as healthy; below 75 percent the site is in the "needs improvement" or "poor" band and pays a ranking penalty. Unlike the lab Performance Score (which measures a synthetic run), this metric is what real users actually experienced on real devices and real networks, sourced from Chrome's anonymised CrUX dataset. | | | | ------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **What it counts** | `(count of real-user page-loads where LCP < 2500ms AND INP < 200ms AND CLS < 0.1) ÷ (total real-user page-loads in the 28-day window) × 100`. The "good" thresholds are Google-defined: LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1. A page-load only counts as passing if **all three** are good simultaneously. | | **Sample type** | **Field data** sourced from Chrome User Experience Report (CrUX). Anonymised aggregate of opted-in Chrome users' real-world page-load measurements over a 28-day rolling window. Lab data (single synthetic run) lives in [`psi_perf_score_summary`](/nerve-centre/kpi-cards/website-performance/performance-score-summary). | | **The 28-day window** | CrUX always reports a 28-day trailing window; this is fixed by Google and not configurable. Any change in CWV pass rate in the dataset reflects 28 days of accumulated user experience, not a moment in time. **Implication**: a deploy that fixes a CWV issue today will not fully reflect in the metric for 28 days; partial reflection happens incrementally as the rolling window absorbs the post-fix sessions. | | **Device split** | CrUX reports separately for mobile (form\_factor: PHONE) and desktop (form\_factor: DESKTOP). The headline figure here defaults to mobile because mobile is the priority for ranking and conversion in ecommerce. Desktop pass rate typically runs 5-15 percentage points higher. The [`crux_mobile_pass`](/nerve-centre/kpi-cards/website-performance/mobile-speed-pass-rate) and [`crux_desktop_pass`](/nerve-centre/kpi-cards/website-performance/desktop-speed-pass-rate) cards surface the split. | | **Sample size threshold** | CrUX requires sufficient real-user traffic to compute a stable p75 metric. Sites below approximately 1,000 page-loads per 28-day window per device may receive partial data (some metrics null) or no data at all. **Low-traffic sites** see this metric as null and must rely on the lab Performance Score; the [`psi_field_vs_lab`](/nerve-centre/kpi-cards/website-performance/field-vs-lab) card surfaces the data-availability gap. | | **Origin vs URL granularity** | CrUX provides two granularities: **origin-level** (aggregate across all URLs for the domain) and **URL-level** (specific page). This card defaults to origin-level (the headline number for the whole site); per-URL data appears in [`crux_origin_vs_url`](/nerve-centre/kpi-cards/website-performance/site-wide-vs-page-performance) and [`psi_all_cwv_pass`](/nerve-centre/kpi-cards/website-performance/all-cwv-pass). | | **What "passing" means commercially** | A site passing CWV (75 percent+ pass rate) qualifies for Google's CWV-related ranking signal in the Core Updates. A site failing CWV (under 75 percent) loses ranking weight in competitive search results. **Industry data** estimates the ranking penalty at 1-3 positions for affected queries; for high-traffic e-commerce keywords, that translates to 10-25 percent organic traffic loss. | | **CrUX vs Lighthouse** | CrUX = field; Lighthouse = lab. **The two should align directionally**; persistent gaps (lab green, CrUX red) suggest real users are on slower hardware/networks than the lab emulation assumes. Common cause: heavy international or low-income audience on older Android devices. | | **Currency** | n/a, this is a percentage. | | **Time window** | `28D` (CrUX-fixed; not configurable). | | **Alert trigger** | `< 75 percent` (Google's CWV-passing threshold). Sub-thresholds: amber 75-90 percent (passing but not best-in-class), red \< 75 percent (failing, ranking penalty active). | | **Sentiment key** | `psi_cwv_pass` | | **Roles** | owner, marketing, 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 home goods store with 480,000 mobile page-views over the most recent 28-day CrUX window and 95,000 desktop page-views. Snapshot for Wednesday 15 May 26. | Device | Total page-loads | LCP good | INP good | CLS good | All-3 good | Pass rate | | ---------------------------- | ---------------: | -------: | -------: | -------: | ---------: | --------: | | Mobile (PHONE) | 480,000 | 76.4% | 89.1% | 81.2% | 311,000 | **64.8%** | | Desktop (DESKTOP) | 95,000 | 91.3% | 97.4% | 89.6% | 78,800 | **82.9%** | | **Origin headline (mobile)** | | | | | | **64.8%** | What the per-device view is telling us: 1. **The 64.8 percent mobile pass rate is in the failing band** (below 75 percent threshold). Google's algorithm is currently treating this site as not-passing-CWV; competitive search queries are losing 1-3 positions of ranking weight. **For an ecommerce brand with significant organic search traffic, this is a measurable revenue drag** and should be treated as a P0 commercial issue, not a "nice-to-have" technical task. 2. **Desktop at 82.9 percent is comfortably passing** but Google weights mobile more heavily for ecommerce ranking signals (mobile-first indexing). A desktop pass rate in green doesn't compensate for a mobile pass rate in red. 3. **LCP at 76.4 percent good is the load-bearing problem.** With 23.6 percent of page-loads failing LCP (taking longer than 2.5 seconds), the site has a structural load-speed issue. Decompose by template: the homepage (heavy hero media) and product detail pages (high-res hero images) likely concentrate the LCP failures. **Fixing LCP from 76.4 → 88 percent good** would lift the all-three pass rate by approximately 8-10 percentage points on its own (more if the LCP failures correlate with INP and CLS failures, which they often do). 4. **INP at 89.1 percent good is healthy.** This is the newer CWV metric (replaced FID in March 2024) and measures click-responsiveness. The site is responsive when users interact; the slow path is initial load, not interaction. Common causes of INP failures: heavy main-thread JS during interaction (sort/filter widgets on collection pages, currency-switcher recalculations). 5. **CLS at 81.2 percent good has room to improve.** Layout shift is typically caused by: images loading without aspect-ratio reservation (banner area shifts when image arrives), web fonts swapping in mid-render (text reflows), late-loading widgets pushing content (Klaviyo popup, chat widget). **Each is fixable with 1-2 days of focused work**: declare aspect ratios in CSS, use `font-display: optional` or preload critical fonts, reserve space for late-loading widgets. 6. **The fix-priority order based on score-impact and effort:** * **First (highest leverage)**: Fix LCP on homepage + PDPs (image optimisation, defer hero video, reduce render-blocking CSS). Estimated lift: +8-12 percentage points to all-three pass rate over 28-day window post-fix. * **Second**: Fix CLS on banner area + late-loading widgets. Estimated lift: +3-5 percentage points. * **Third (already healthy)**: monitor INP for regression but no active work needed. 7. **The 28-day window timing.** A deploy fixing the LCP issue today will produce a partially-improved pass rate in 7 days (week-1 of 28-day window absorbs new sessions), substantially-improved at 14 days, fully-reflected at 28 days. **Patience required**: the metric is lagging by design; reading it weekly is the right cadence. The diagnostic flow when this card flags failing (\< 75 percent): 1. **Decompose by metric.** Per-metric pass rates surface which CWV is dragging the all-three composite. The fix priority follows the worst-performing metric. 2. **Decompose by URL / template.** [`crux_origin_vs_url`](/nerve-centre/kpi-cards/website-performance/site-wide-vs-page-performance) shows whether the site-wide failure concentrates on specific URLs (homepage, PDP, collection) or is diffuse across templates. 3. **Cross-reference with lab data.** If lab is green and field is red, the issue is real-user-condition-specific (slow devices, slow networks). If both red, the site has structural issues independent of user conditions. 4. **Pair with traffic mix.** Audiences with heavy international, low-income, or older-device share will show worse field metrics than lab regardless of optimisation work. The optimisation target should be calibrated to audience profile. 5. **Plan to the 28-day window.** Don't expect overnight movement. Track 7-day rolling deltas for early signal; track 28-day rolling for the headline truth. The rapid-response playbook for marketing operations + engineering: | Time horizon | Action | | ------------------------ | ------------------------------------------------------------------------------------------------------ | | First 1 hour after alert | Identify which CWV is dragging (LCP, INP, or CLS). Decompose by URL/template. | | First 24 hours | Plan the fix work. Concentrate on the highest-leverage metric (typically LCP). | | First 7 days | Implement fix. Deploy to production. | | Days 7-28 | Monitor 7-day rolling pass rate for early signal. Confirm fix works in field conditions, not just lab. | | Day 28 onward | Headline 28-day pass rate fully reflects fix. Re-evaluate position; move to next metric if needed. | ## Sibling cards merchants should reference together | Card | Why merchants reach for it | | ---------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | | [`crux_lcp_p75`](/nerve-centre/kpi-cards/website-performance/page-load-speed) | LCP-specific p75 view. The most-recognised CWV; biggest single contributor to pass-rate failure. | | [`crux_inp_p75`](/nerve-centre/kpi-cards/website-performance/click-responsiveness) | INP-specific p75 view. Click-responsiveness signal. | | [`crux_cls_p75`](/nerve-centre/kpi-cards/website-performance/layout-stability) | CLS-specific p75 view. Layout stability signal. | | [`crux_lcp_distribution`](/nerve-centre/kpi-cards/website-performance/load-speed-distribution) | LCP good/needs-improvement/poor distribution. Where exactly the threshold is failing. | | [`crux_inp_distribution`](/nerve-centre/kpi-cards/website-performance/responsiveness-distribution) | INP distribution. | | [`crux_cls_distribution`](/nerve-centre/kpi-cards/website-performance/layout-shift-distribution) | CLS distribution. | | [`crux_mobile_pass`](/nerve-centre/kpi-cards/website-performance/mobile-speed-pass-rate) | Mobile-only pass rate. The priority device for ranking. | | [`crux_desktop_pass`](/nerve-centre/kpi-cards/website-performance/desktop-speed-pass-rate) | Desktop pass rate. Typically 5-15 points higher than mobile. | | [`crux_origin_vs_url`](/nerve-centre/kpi-cards/website-performance/site-wide-vs-page-performance) | Origin-level vs per-URL pass rate. Surfaces whether failure concentrates on specific pages. | | [`crux_pass_rate_trend`](/nerve-centre/kpi-cards/website-performance/speed-test-pass-rate-over-time) | Pass rate over time. Drift detection given the 28-day window lag. | | [`psi_perf_score_summary`](/nerve-centre/kpi-cards/website-performance/performance-score-summary) | Lab equivalent. Pair with this card for lab-vs-field analysis. | | [`psi_field_vs_lab`](/nerve-centre/kpi-cards/website-performance/field-vs-lab) | Direct lab-vs-field gap analysis. Surfaces real-user-condition-specific issues. | | [`psi_all_cwv_pass`](/nerve-centre/kpi-cards/website-performance/all-cwv-pass) | Per-page CWV pass status. Page-level granularity. | | [GSC `gsc_mobile_usable_pages`](/nerve-centre/google_search_console/gsc_mobile_usable_pages) | Pairs with CWV pass rate for the full mobile-readiness picture. | | [GA4 `ga_pageviews_per_session`](/nerve-centre/kpi-cards/google-analytics/pageviews-per-session) | Engagement metric correlating with site speed. Slow sites see lower depth-of-engagement. | ## Reconciling against the vendor's own dashboard **Where to look in PageSpeed Insights / GSC / CrUX's own dashboards:** * **[Google Search Console → Core Web Vitals report](https://search.google.com/search-console)**, the canonical view for the CWV pass rate Google uses for ranking signals. Shows pass / needs-improvement / poor URL counts per device with the same 28-day CrUX window. * **[PageSpeed Insights](https://pagespeed.web.dev)**, the field-data section at the top of the report shows the same origin-level CrUX pass percentages. * **[CrUX Dashboard via Looker Studio](https://lookerstudio.google.com/c/u/0/reporting/55bc8fad-44c2-4280-aa0b-5f3f0cd3d2be/page/M6ZPC)**, Google's official CrUX explorer for deeper trend analysis. * **[CrUX BigQuery dataset](https://github.com/GoogleChrome/CrUX)**, for advanced users wanting raw monthly CrUX data. **Why the Vortex IQ pass rate may legitimately differ from GSC or PSI:** | Reason | Direction | What to do | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | | **Window timing.** Vortex IQ refreshes the CrUX pull on a daily cadence; GSC and PSI both serve the most recent CrUX dataset. The most recent 24-48 hours of CrUX update may not yet be in the Vortex IQ cache. | Vortex IQ **lags** for 1-2 days | Wait for next refresh; check `last_synced_at`. | | **Origin-level vs URL-level.** Vortex IQ headline shows origin-level (whole site); GSC report defaults to URL-grouped. Sites with one heavy URL (e.g. homepage) dragging origin-level performance see the origin number drop while specific URLs may pass. | Often diverging interpretation | Use [`crux_origin_vs_url`](/nerve-centre/kpi-cards/website-performance/site-wide-vs-page-performance) for the per-URL view. | | **Form factor default.** Vortex IQ headline defaults to mobile (PHONE form\_factor); GSC report shows both with toggle. PSI defaults to mobile too. | n/a if both on mobile | Confirm both views are on the same form factor. | | **CrUX data availability.** Sites with low traffic may have partial CrUX data (some metrics null); both Vortex IQ and PSI handle this similarly but may differ in how they composite the available metrics. | Either direction | For low-traffic sites, treat the metric as unreliable and rely on lab data. | | **CrUX dataset version.** Google publishes a new CrUX dataset monthly (typically second Tuesday). Vortex IQ pulls the latest available; some external dashboards may cache for longer. | Either direction | The monthly publication boundary can produce step-changes that look like anomalies but are dataset transitions. | **Cross-connector reconciliation:** | Comparison | Expected relationship | When divergence is legitimate | | ----------------------------------------------------------------------------------------------------------------------- | ----------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `psi_cwv_pass_rate` ↔ [`psi_perf_score_summary`](/nerve-centre/kpi-cards/website-performance/performance-score-summary) | Field and lab directionally agree | Persistent gaps (lab green, field red) suggest real users on slower hardware/networks than lab emulation assumes. Common cause: heavy international or low-income audience. | | `psi_cwv_pass_rate` ↔ [GSC Core Web Vitals report](/nerve-centre/google_search_console/gsc_mobile_usable_pages) | Should match within 1-2 percentage points | Same data source (CrUX); divergence usually indicates window-timing differences. | | `psi_cwv_pass_rate` ↔ [GA4 conversion rate](/nerve-centre/kpi-cards/google-analytics/ecommerce-conversion-rate) | Positive correlation over time | Sites moving from failing to passing CWV typically see 1-3 percent conversion rate uplift. The relationship is well-documented in industry studies. | | `psi_cwv_pass_rate` ↔ Internal RUM (real-user monitoring) tools (Datadog RUM, New Relic Browser, etc.) | Should align within 5 percentage points | Internal RUM tools sample your traffic directly; CrUX samples opted-in Chrome users. Cohort differences (Safari users excluded from CrUX, browser-extension noise) explain modest divergence. Persistent large gaps suggest CrUX-vs-RUM cohort skew. | **Quick rule for support tickets:** if a merchant says *"GSC shows my CWV passing but your card shows failing"*, the most common cause is the form-factor toggle (GSC defaults to "All" or "Desktop"; Vortex IQ defaults to mobile-only). The next-most-common is window timing (Vortex IQ lags 1-2 days). If neither applies and the gap exceeds 5 percentage points, check the origin-vs-URL aggregation: GSC shows pass/fail per URL group; Vortex IQ shows the origin-level aggregate. ## Known limitations / merchant FAQs **My CWV pass rate is 64 percent. How fast can I get to 75 percent?** Depends on the underlying issue and the 28-day window timing. **Realistic recovery timeline**: (1) Day 1-7: identify and fix the dragging metric; deploy. (2) Day 7-14: 7-day rolling pass rate begins to show movement as new sessions accumulate. (3) Day 14-28: 28-day rolling pass rate progressively absorbs the post-fix sessions. (4) Day 28+: full reflection of the fix. **For LCP issues with clean fixes** (image optimisation, defer hero video), expect 8-12 percentage point lift over the 28-day window post-fix. For CLS fixes, expect 3-5 points. For INP fixes (less common need), expect 2-4 points. Brands at 60-65 percent pass rate can typically reach 75+ within 6-8 weeks of disciplined work; brands below 50 percent often need 3-4 months and structural theme changes. **My GSC report shows different pass rates than your card. Which is right?** Both are correct; they are looking at slightly different slices. GSC defaults to grouping by URL pattern and showing pass/needs-improvement/poor URL counts; Vortex IQ defaults to origin-level pass percentage. Use the toggle in GSC to switch to the same form factor and aggregation. **For ranking-impact decisions, GSC is the canonical source** because it's what Google's algorithm sees. Vortex IQ uses the same CrUX data underneath; gaps come from refresh-timing or aggregation level. **Why does the metric not change after I deployed a fix?** The 28-day window. CrUX always reports a 28-day rolling aggregate; today's metric value is an average of the past 28 days of real-user sessions. A fix deployed today won't fully reflect for 28 days; partial reflection happens incrementally as the new sessions accumulate in the window. **Watch the 7-day rolling delta for early signal**; the headline 28-day number is intentionally lagging. **My site has low traffic and CrUX returns null. What do I use instead?** Lab data. The [`psi_perf_score_summary`](/nerve-centre/kpi-cards/website-performance/performance-score-summary) lab score doesn't require any traffic; Lighthouse runs synthetically. For low-traffic sites that lack CrUX data: anchor on the lab Performance Score and the per-CWV lab metrics ([`psi_lab_lcp`](/nerve-centre/kpi-cards/website-performance/lab-load-speed), [`psi_lab_tbt`](/nerve-centre/kpi-cards/website-performance/page-freeze-time), [`psi_lab_cls`](/nerve-centre/kpi-cards/website-performance/lab-layout-stability)). Once traffic grows past CrUX's volume threshold (\~1,000 sessions/28 days), the field metrics will start populating and become the primary signal. **Does Google really penalise sites in the failing band?** Yes, but the impact is variable. CWV is one signal among many in Google's ranking algorithm; for highly competitive queries with multiple capable competitors, CWV can be a 1-3 position differentiator. For less competitive queries, the impact is smaller. **The conservative read**: failing CWV costs you measurable ranking on competitive queries; passing CWV doesn't necessarily lift you above competitors who also pass. Treat passing as table-stakes, not as a competitive advantage. **Should I prioritise mobile or desktop?** Mobile, almost always. Mobile-first indexing means Google primarily evaluates mobile performance for ranking. Mobile typically accounts for 60-80 percent of ecommerce traffic. The mobile pass rate is the priority signal; desktop pass rate is a secondary check. **My CWV is passing on the homepage but failing on PDPs. What should I do?** Concentrate fix work on PDPs. **PDPs typically receive direct traffic from paid search and email**, where the user has high purchase intent; performance issues there have outsized conversion impact. Homepage performance matters for branded search and direct visits, but PDP performance directly drives revenue. The [`crux_origin_vs_url`](/nerve-centre/kpi-cards/website-performance/site-wide-vs-page-performance) card surfaces the per-URL split. **Why do I need to wait 28 days to see if my fix worked?** You don't, for early signal. The 7-day rolling delta surfaces movement within the first week. Use it for "is the fix working?" check. Wait for the 28-day window for "is the fix fully reflected?" answer. The two-step approach (early signal at 7 days, full confirmation at 28 days) is the right cadence. **Can Vortex IQ run audits more frequently than CrUX updates?** CrUX updates monthly (with the rolling 28-day window calculated daily within Google's pipeline). Vortex IQ pulls the latest CrUX data daily, so the metric refreshes daily even though the underlying data has a structural cadence. Lab audits via Lighthouse run on Vortex IQ's schedule (hourly to daily depending on integration tier). **My site is on Catalyst not Stencil. Are CWV expectations different?** Catalyst (BC's Next.js-based stack) has structurally better performance characteristics than Stencil for most use cases (server-side rendering, code-splitting, automatic image optimisation). **Catalyst-on-default-config typically scores 75-85 percent CWV pass rate** out of the box; the optimisation ceiling is higher (90+) but achievable with less custom work. Stencil sites typically need more aggressive optimisation work to reach the same band. Brands considering migration: CWV improvement is one of the strongest commercial cases for the migration alongside multi-language and developer-velocity benefits. **Can Vortex IQ improve my CWV automatically?** Read-only by design. Vortex IQ surfaces pass-rate patterns, identifies dragging metrics, and ranks optimisation opportunities; the merchant's developers or agency execute inside the BC theme or Catalyst codebase. The Vortex Mind Pre-Launch Readiness report generates merchant-side Actions but the changes themselves sit with the merchant. *** ### Tracked live in Vortex IQ Nerve Centre *Speed Test Pass Rate* 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.