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. |
| 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 and crux_desktop_pass 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 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 and psi_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% |
- 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.
- 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.
- 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).
- 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).
-
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: optionalor preload critical fonts, reserve space for late-loading widgets. -
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.
- 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.
- Decompose by metric. Per-metric pass rates surface which CWV is dragging the all-three composite. The fix priority follows the worst-performing metric.
- Decompose by URL / template.
crux_origin_vs_urlshows whether the site-wide failure concentrates on specific URLs (homepage, PDP, collection) or is diffuse across templates. - 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.
- 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.
- 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.
| 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 | LCP-specific p75 view. The most-recognised CWV; biggest single contributor to pass-rate failure. |
crux_inp_p75 | INP-specific p75 view. Click-responsiveness signal. |
crux_cls_p75 | CLS-specific p75 view. Layout stability signal. |
crux_lcp_distribution | LCP good/needs-improvement/poor distribution. Where exactly the threshold is failing. |
crux_inp_distribution | INP distribution. |
crux_cls_distribution | CLS distribution. |
crux_mobile_pass | Mobile-only pass rate. The priority device for ranking. |
crux_desktop_pass | Desktop pass rate. Typically 5-15 points higher than mobile. |
crux_origin_vs_url | Origin-level vs per-URL pass rate. Surfaces whether failure concentrates on specific pages. |
crux_pass_rate_trend | Pass rate over time. Drift detection given the 28-day window lag. |
psi_perf_score_summary | Lab equivalent. Pair with this card for lab-vs-field analysis. |
psi_field_vs_lab | Direct lab-vs-field gap analysis. Surfaces real-user-condition-specific issues. |
psi_all_cwv_pass | Per-page CWV pass status. Page-level granularity. |
GSC gsc_mobile_usable_pages | Pairs with CWV pass rate for the full mobile-readiness picture. |
GA4 ga_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, 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, the field-data section at the top of the report shows the same origin-level CrUX pass percentages.
- CrUX Dashboard via Looker Studio, Google’s official CrUX explorer for deeper trend analysis.
- CrUX BigQuery dataset, for advanced users wanting raw monthly CrUX data.
| 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 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. |
| Comparison | Expected relationship | When divergence is legitimate |
|---|---|---|
psi_cwv_pass_rate ↔ psi_perf_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 | Should match within 1-2 percentage points | Same data source (CrUX); divergence usually indicates window-timing differences. |
psi_cwv_pass_rate ↔ GA4 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. |
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. Thepsi_perf_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, psi_lab_tbt, psi_lab_cls). 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 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.