Slow page → conversion rate drop. Names the page so the dev can fix it the same morning.
At a glance
Cross-references each landing page’s Largest Contentful Paint (LCP) from CrUX/PageSpeed against its GA4 conversion rate. The card surfaces individual landing pages where LCP is poor (>4s) AND conversion rate is less than half the site average. Names the slow-and-converting-poorly page so engineering can fix it that morning rather than chasing a generic “site is slow” signal.
| What it counts | For every landing page with ≥500 sessions in the window: (GA4 sessionConversionRate for that landing) ÷ (GA4 sessionConversionRate site-wide average), intersected with (CrUX LCP p75 for that landing) > 4000ms. Pages meeting both criteria are listed; the card surfaces the worst N. |
| Sample basis | Two data sources joined by URL path. (1) GA4 runReport with dimension landingPage and metrics sessionConversionRate, sessions. (2) CrUX (Chrome User Experience Report) p75 LCP per URL, OR PageSpeed Insights field data if CrUX has no entry for the URL. The 500-session minimum is the floor for statistical reliability. |
| Sampling threshold | None for the GA4 side at 30D + landing-page dimension (low-cardinality). CrUX is itself a Google sample (28-day rolling Chrome users) and only includes URLs with sufficient traffic; URLs below CrUX’s sample floor get PageSpeed lab data instead, which is less precise. |
| Bot traffic filter | GA4: built-in IAB Tech Lab filter applied. CrUX: Chrome-only, real users only (no bots reach CrUX). Both sides post-filter. |
| Time zone | GA4 side: property timezone. CrUX side: rolling 28-day window in the page’s geographic distribution; not strictly aligned to a single zone. |
| Currency | Not applicable, this card uses LCP (milliseconds) and CR (percent), not revenue. The downstream impact is revenue, but the metric itself is unitless ratios. |
| Refunds | Not applicable, CR is purchase-event count ÷ sessions, gross of refunds. |
| Tracking-gap framing | The GA4 CR side carries the structural tracking gap (10, 25%). Because the gap is roughly proportional across landing pages, the relative CR comparison (this page vs site average) is stable even if absolute CRs are understated. |
| Time window | 30D (single window; LCP is more stable than CR, so vsP isn’t needed). |
| Alert trigger | any landing with LCP >4s AND CR <0.5×site-avg, the 0.5× multiplier excludes pages that are “just OK”; this card targets the painful outliers worth fixing. |
| Roles | owner, marketing, engineering |
Calculation
Calculated automatically from your Google Analytics 4 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 US outdoor-gear brand on BigCommerce. 30-day window ending 02 May 26. Site-average CR is 2.4%.| Landing page | Sessions | LCP p75 (CrUX) | CR | CR vs site-avg | Status |
|---|---|---|---|---|---|
/category/tents | 18,400 | 1.8s | 3.1% | 1.29× | Healthy (fast + above-avg CR) |
/products/four-season-tent | 9,200 | 2.3s | 4.6% | 1.92× | Star (fast + best-converter) |
/blog/how-to-pack-a-backpack | 6,800 | 4.7s | 0.8% | 0.33× | Alert: LCP >4s AND CR <0.5× |
/category/sleeping-bags | 12,100 | 5.4s | 0.9% | 0.38× | Alert: LCP >4s AND CR <0.5× |
/about-us | 3,400 | 3.1s | 0.4% | 0.17× | Below alert (LCP <4s, content page) |
- The card names the two pages worth fixing this morning. Not “your site is slow” (a hopeless brief for engineering); it names
/category/sleeping-bagsand/blog/how-to-pack-a-backpackspecifically. Both have >5,000 sessions in the window, so the CR signal is statistically meaningful, not noise. The blog page’s poor CR is partly expected (blog readers convert worse than category browsers), but at 0.33× site-avg AND LCP 4.7s, it’s worse than peer-blog benchmarks; the slow render is suppressing already-low intent. - The /category/sleeping-bags fix is high-leverage. 12,100 sessions × current 0.9% CR = 109 conversions in the window. Site-avg CR (2.4%) × 12,100 = 290 conversions. The page is leaving ~180 conversions on the floor due to performance. At an average order value of 26,000 of revenue per month. A two-week engineering investment to optimise images, defer non-critical JS, and pre-load the hero image is straightforwardly profitable.
- /about-us doesn’t trigger the alert despite low CR. That’s by design. Content-marketing pages have natively lower CR than category pages because the user intent is informational, not transactional. The alert filters by both LCP poor AND CR <0.5× site-avg; /about-us has acceptable LCP (3.1s) so it stays off the list. The card targets the intersection of slow-and-failing, not slow-OR-failing.
- CrUX vs PageSpeed lab data. For high-traffic landing pages (>=200 daily Chrome users in the geographic distribution), CrUX provides field LCP data which is the gold standard. For lower-traffic pages, the engine falls back to PageSpeed Insights synthetic lab data, which is less precise but directionally reliable. The card flags lab-derived rows with a small icon so engineering knows the LCP value is approximate.
- What WOULD generate a “no alerts” state? A site where (a) every landing page has LCP under 4s, OR (b) the few slow pages happen to also have CR ≥ 0.5× site-avg (rare; speed correlates with CR). A clean state on this card means your site performance work has paid off.
Sibling cards merchants should reference together
| Card | Why pair it with LCP-to-Conversion Correlation |
|---|---|
| GA4 Conversion by Landing Page | The pure GA4 view: CR per landing page. This card adds the LCP cross-reference, so engineering knows why a page is converting poorly. |
| GA4 Top Landing Pages | The volume side. A slow-and-poor-converting page with low traffic is less urgent than a slow-and-poor-converting page that’s a top landing. |
| Website LCP / Website CrUX Core Web Vitals | The performance truth side. Use to validate the LCP figures this card surfaces and to understand the underlying CrUX p75 distribution. |
| Website PageSpeed Score | The synthetic lab counterpart to CrUX field data. Useful for low-traffic pages where CrUX has no data. |
| GA4 Conversion Rate | The site-wide reference number. The 0.5× multiplier in this card’s alert is anchored to this metric. |
| GA4 Bounce by Landing | Companion: slow LCP often correlates with high bounce. If a flagged page has both poor CR AND high bounce, the LCP fix has compound impact. |
| Cross-channel: Revenue at Risk from Incident | If a landing page suddenly degrades from healthy to alert state, the revenue-at-risk card may show a related incident-driven hit. |
| Shopify / BC / Adobe Total Revenue | Truth side for the revenue-impact calculation underlying engineering prioritisation. |
Reconciling against the vendor’s own dashboard
Where to look in GA4 (this card joins GA4 + CrUX, not GA4-only): GA4 doesn’t have a single screen showing “LCP × CR per landing page”. The closest manual rebuild requires two separate views:Reports → Engagement → Landing pages → Add metric: “Session conversion rate” for the GA4 side. Open Google PageSpeed Insights (pagespeed.web.dev) and submit each top-landing URL to retrieve CrUX field LCP. Or use Google Search Console → Core Web Vitals report for an aggregate view.Other GA4 views that look like this but aren’t:
- Reports → Tech → Tech overview: device/browser breakdown of bounce; doesn’t surface per-page LCP.
- Web Vitals events (custom): some merchants instrument web-vitals.js to send LCP as custom GA4 events. If you have that setup, the data is more precise but lives in custom dimensions, not standard reports.
- Realtime → Events → page_view: 30-min lookback only; useful for confirming page-view tracking is healthy, not for LCP-CR correlation.
| Reason | Direction of divergence |
|---|---|
| CrUX 28-day rolling window. CrUX p75 is a rolling 28-day field-data sample, not aligned to the GA4 30D window. The two windows overlap ~93% but the 7% non-overlap can shift LCP for pages with recent perf changes. | Up to ±300ms on pages with recent code deploys |
| PageSpeed lab fallback. For low-traffic URLs without CrUX data, we use PageSpeed lab simulations. Lab data on Moto-G4-3G is conservative; real-world distributions can be faster. | Lab values typically 500, 1500ms slower than field |
URL canonicalisation. We treat /category/tents and /category/tents/ as the same page; GA4 may report them as separate rows if your site doesn’t 301 between them. | Per-URL CR may split |
| Mobile vs desktop LCP. CrUX reports separate p75 for mobile and desktop; this card uses mobile (the worse of the two) by default. If you compare against desktop CrUX values you’ll see lower (faster) LCP. | Mobile typically 500, 2000ms slower than desktop |
| Cross-domain landing pages. Multi-storefront properties may have landing pages on subdomains; the CrUX data is per-origin, GA4 may aggregate across origins if not configured to track them separately. | Variable |
| Card | Relationship | What divergences mean |
|---|---|---|
website_performance.lcp | The LCP value used in this card matches the website-performance card’s CrUX p75 reading. | A divergence = stale CrUX data or different URL canonicalisation. |
website_performance.crux | Same source data. | Same. |
google_analytics.conversion_by_landing | The CR-per-landing-page values match this card. | A divergence = different windowing or sampling state (this card has a 500-session minimum that conversion_by_landing doesn’t enforce). |
shopify.total_revenue / bigcommerce.total_revenue / adobe_commerce.total_revenue | Used in the underlying revenue-at-risk calculation: (sessions × site-avg-CR × AOV) - (sessions × actual-CR × AOV) per flagged page. | The revenue numbers respect the structural GA4 tracking gap; the IMPACT estimate is conservative (commerce-platform truth would show a larger absolute lift from a fix). |
Known limitations / merchant FAQs
Why is my GA4 conversion-rate-by-landing-page lower than commerce-platform CR? Same answer as for GA4 Conversion Rate: GA4 misses 10, 25% of purchase events to ad blockers and consent rejection. The relative comparison (this page vs site average) is robust because the gap is roughly proportional across pages; the absolute CR is understated. Why does the alert use 4-second LCP threshold? Google says “Good” is <2.5s. Google’s published thresholds are: <2.5s “Good”, 2.5, 4s “Needs Improvement”, >4s “Poor”. This card’s alert uses the 4s threshold (Poor) because pages above 4s have measurable, well-documented business impact (Google’s own studies show CR drops ~5, 10% per second of additional LCP above 2.5s). Below 4s, the impact is real but smaller and harder to quantify per page. The 4s threshold targets the unambiguously-painful pages, not borderline cases. Why the 0.5× site-average multiplier on CR? Many landing pages naturally convert below site average for legitimate reasons: blog content (informational intent), about-us, contact, FAQ. Without the multiplier, this card would flag every non-product landing page. The 0.5× threshold isolates pages that convert catastrophically below their peers, where it’s likely the slow LCP suppressing conversion rather than just intent mix. My flagged page is /blog/ . Are blog pages supposed to convert?* Not as well as category or product pages, but they should still beat 0.5× site-avg for healthy content marketing. A blog page at 0.33× site-avg with 4.7s LCP is doing two things wrong: (1) the LCP is making impatient readers leave before reading enough to develop intent, and (2) the page may lack a strong purchase CTA. Fix the LCP first; CTAs can be A/B-tested afterwards. My CrUX data shows X but PageSpeed Insights shows Y. Which is right? CrUX is field data (real users); PageSpeed lab data is a synthetic simulation on Moto-G4-3G. Field is the truth; lab is the diagnostic tool. This card prefers CrUX field data when available; lab data is a fallback. If CrUX shows your page is fast (under 2.5s) but PageSpeed lab shows it slow, your real users on better hardware are fine, but the page is fragile and could regress for users on lower-end devices. My page is fast in CrUX but flagged anyway. Why? Re-read the alert: “LCP >4s AND CR <0.5×”. If the page passes the LCP test but CR is poor, it isn’t flagged by this card. Check GA4 Conversion by Landing for non-LCP-driven CR issues. This card only flags the intersection. Does this card account for mobile vs desktop separately? Partially. The CrUX side defaults to mobile p75 (the worse of the two device classes). The GA4 side aggregates across devices. For a more granular view, use GA4 Conversion by Device alongside Website LCP, which breaks LCP by device. A future iteration of this card may split by device. A flagged page just got fixed (LCP from 5s to 1.8s). Will the card update immediately? The CrUX side updates with a 28-day rolling window, so the LCP improvement will visibly land in CrUX over ~7, 14 days as new field data dilutes the old. The GA4 side will pick up CR improvements within the next 30D window roll. Don’t expect this card to clear within 24h of a deploy; allow ~2 weeks for the rolling windows to reflect the fix. The flagged page is on a 3rd-party domain (e.g. our help-centre is on Zendesk). What can we do? This card surfaces the issue but the fix is on the third-party platform’s roadmap, not yours. If the third-party page is on a subdomain you control, you can sometimes optimise via custom CSS/JS injection. If it’s fully external, prioritise reducing traffic there (or moving the help content to your own performant infrastructure) rather than waiting on the vendor’s perf work. What’s the typical revenue lift from fixing one flagged page? Order of magnitude: (page_sessions / 30) × (site-avg-CR − current-CR) × AOV × 30 days = monthly revenue recovered. For the worked-example brand’s/category/sleeping-bags page: (12,100/30) × (2.4% − 0.9%) × 26,000/month. The card’s tooltip surfaces this estimate per row.