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.
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.
What the per-device view is telling us:
- 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.
Sibling cards merchants should reference together
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.
Cross-connector reconciliation:
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. 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.