At a glance
Largest Contentful Paint at the 75th percentile. The time at which the largest meaningful content element (typically the hero image, hero video, or main heading text) finishes rendering, measured from the moment navigation started. The p75 means: 75 percent of real users experienced LCP at this value or faster; 25 percent experienced it slower. Google’s “good” threshold is 2.5 seconds, sites at p75 LCP under 2.5s pass this CWV; over 4 seconds is “poor”. The single most important load-speed metric for ecommerce because it directly correlates with bounce rate: every 1 second of LCP delay above 2.5s adds approximately 8-12 percent to bounce rate.
| What it counts | The 75th-percentile of largest_contentful_paint measurements across all real-user page-loads in the 28-day CrUX window. The metric measures from navigationStart to the moment the LCP element finishes rendering. The “LCP element” is automatically detected as the largest above-the-fold element (image, video poster, h1 text block) by render area at first-paint time. |
| Sample type | Field data sourced from Chrome User Experience Report (CrUX). Real users on real devices on real networks. Lab equivalent: psi_lab_lcp. |
| Device split | Mobile (PHONE) is the headline; desktop typically runs 30-50 percent faster. Mobile LCP is structurally slower because: slower CPUs (mobile-emulated mid-tier), throttled networks (4G vs unthrottled fiber), smaller viewports causing different LCP elements to be selected. |
| Google thresholds | Good: ≤ 2500ms (passes CWV). Needs improvement: 2500-4000ms. Poor: > 4000ms (fails CWV, ranking penalty active). The thresholds are Google-defined and apply uniformly across all sites. |
| Sample size threshold | CrUX p75 calculation requires sufficient real-user volume (~1,000+ page-loads per 28-day window per device per metric). Low-traffic sites see this metric as null. |
| The 28-day window | CrUX always reports a 28-day trailing window. Performance changes (deploys, optimisations, regressions) take 28 days to fully reflect; partial reflection happens incrementally. |
| What drives LCP slowness | (a) Heavy hero images: unoptimised PNG or JPEG above the fold, especially on mobile where smaller display still serves the same large image. (b) Hero video carousel: video files force download before LCP can complete. (c) Render-blocking CSS: external stylesheets blocking the critical render path. (d) Render-blocking JS: synchronous third-party scripts in <head> forcing JS parse before render. (e) Slow server response: TTFB over 600ms (covered by crux_ttfb_p75). (f) CDN cache miss: cold-cache requests serve from origin instead of edge. |
| Common ecommerce LCP patterns | Stencil-themed BC sites: hero image carousel (unoptimised PNG, 2-4MB per slide). Catalyst sites: better defaults but still vulnerable to large hero images if not configured for next/image. Shopify Online Store 2.0: similar to Stencil patterns. |
| Optimisation playbook | (1) Optimise hero image: WebP or AVIF, compressed to 80-85 quality, served at display size for mobile. (2) Defer hero video to post-load. (3) Inline critical CSS, defer non-critical CSS. (4) Use <link rel="preload"> on the hero image. (5) Move third-party scripts out of <head> and load with defer or async. Each step typically saves 200-800ms of mobile p75 LCP. |
| Currency | n/a, this is a duration in milliseconds. |
| Time window | 28D (CrUX-fixed). |
| Alert trigger | > 2500ms (Google’s good threshold). Sub-thresholds: amber 2500-4000ms (needs improvement), red > 4000ms (poor). |
| Sentiment key | psi_lcp |
| 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 fashion store, 480,000 mobile page-views over 28 days, Stencil theme with hero carousel + Klaviyo popup + chat widget. Snapshot Wednesday 15 May 26.| Page template | Mobile p75 LCP | Desktop p75 LCP | Google band | Driver |
|---|---|---|---|---|
| Homepage | 4,820ms | 2,140ms | Poor (mobile) | Hero carousel: 4 unoptimised PNGs at 2.8MB each |
| Product detail page | 3,640ms | 1,890ms | Needs improvement | Hero product image: 1.6MB JPEG |
| Collection / category | 4,210ms | 2,310ms | Poor | 12-image grid loads all images upfront |
| Cart | 2,180ms | 1,420ms | Good | Lighter, no media |
| Checkout step 1 | 1,940ms | 1,180ms | Good | Lightest, no third-party scripts |
| Origin p75 (mobile) | 3,920ms | Needs improvement (close to poor) |
- The 3,920ms origin p75 LCP is in the “needs improvement” band but only 80ms from the “poor” boundary (4000ms). The site is one bad-deploy or one heavy image upload from dropping into red. A defensive 500ms cushion is needed: bring origin LCP to ~3400ms or below to avoid the cliff.
-
Homepage at 4,820ms is the structural problem. With 4 unoptimised hero PNGs at 2.8MB each, the LCP element (whichever PNG is selected as largest) downloads 2.8MB on a 4G mobile connection, taking 3-5 seconds even before render begins. The fix is mechanical: convert to WebP at 80 quality, serve mobile-sized variants via
srcset, lazy-load slides 2-4. Estimated post-fix: 1,800-2,400ms LCP, dropping origin p75 to ~2,800ms. -
PDPs at 3,640ms are needs-improvement but recoverable. The hero product image at 1.6MB JPEG can compress to 250-400KB at 85 quality WebP without visible quality loss. Combined with
<link rel="preload">on the image and properloading="eager", expect 1,800-2,200ms post-fix. -
Collection pages at 4,210ms (poor band) need more aggressive work. The 12-image grid loading all images upfront is wasteful: at most 4 images are above the mobile fold. Add
loading="lazy"to images 5-12: that alone often drops collection-page LCP by 800-1,200ms. Combined with image-format conversion, expect collection pages in the 2,400-2,800ms range. - The cart and checkout pages are healthy. Don’t touch them. Common mistake: optimisation work concentrating on transactional pages because they “feel important”. The data says these pages are already fast; the work belongs on public-facing pages where slow load directly costs traffic and conversion.
- Commercial impact estimation. If the site has 30 percent of mobile traffic landing on the homepage and 25 percent on PDPs (typical for branded ecommerce), and if every 1 second of LCP delay over 2.5s adds 8-12 percent bounce rate: current homepage is at 4.82s = 2.32s over threshold = ~22 percent additional bounce above baseline. At 480k monthly mobile sessions × 30 percent on homepage × 22 percent additional bounce = ~31,700 lost sessions/month. At 2 percent conversion rate × £42 AOV, that’s roughly £26,600 of monthly revenue at risk from homepage LCP alone.
- Identify the LCP element. PageSpeed Insights “Diagnostics” section identifies the element selected as LCP. Common culprits: hero image, video poster, h1 text block when no images are above-the-fold.
- Decompose by template.
psi_lcp_by_templateshows per-template LCP. Concentrate work on templates with high traffic share AND poor LCP. - Cross-reference TTFB. Slow LCP often starts with slow TTFB. If
crux_ttfb_p75is over 600ms, server response is the bottleneck and image optimisation alone won’t fix LCP. - Check render-blocking resources.
psi_render_blockingsurfaces stylesheets and scripts blocking first paint. These delay LCP indirectly by delaying the render pipeline. - For the demo’s BC sandbox, the homepage hero image is almost certainly the dominant factor, image optimisation is the highest-leverage fix.
| Time horizon | Action |
|---|---|
| First 1 hour after alert | Identify LCP element; identify template most-affected. |
| First 4 hours | Optimise hero image format (WebP/AVIF) and dimensions; add preload directive. |
| First 24 hours | Deploy. Lab LCP should drop immediately; field LCP starts shifting at 7-day rolling. |
| First 7 days | 7-day rolling field LCP shows partial movement. Confirm direction. |
| Day 28 | 28-day rolling fully reflects fix. Re-evaluate against the next-priority template. |
Sibling cards merchants should reference together
| Card | Why merchants reach for it |
|---|---|
crux_lcp_distribution | LCP good/needs-improvement/poor distribution. Where exactly the threshold is failing. |
crux_lcp_trend | LCP over time; drift detection. |
psi_lab_lcp | Lab LCP, the synthetic-conditions equivalent. |
psi_lcp_by_template | Per-template LCP. Surfaces which page types drag the origin number. |
psi_slowest_lcp_urls | Specific worst-performing URLs. The fix-priority list. |
crux_ttfb_p75 | Server response time. LCP can’t be fast if TTFB is slow. |
crux_fcp_p75 | First Contentful Paint, the precursor metric to LCP. |
psi_render_blocking | Resources blocking first paint. Delay LCP indirectly. |
psi_image_optimisation | Image-specific optimisation opportunities. The most common LCP fix. |
psi_total_weight | Total page weight; correlates with LCP especially on slow networks. |
psi_third_party_cost | Third-party script cost. Often pushes LCP up indirectly via render-blocking. |
psi_perf_score_summary | The composite score. LCP is 25 percent of the weight. |
psi_cwv_pass_rate | All-three CWV gate. LCP failing alone fails the gate. |
GSC gsc_average_position | Search ranking; LCP failure costs ranking on competitive queries. |
GA4 ga_bounce_by_device | Bounce rate; correlates negatively with LCP. |
Reconciling against the vendor’s own dashboard
Where to look in PageSpeed Insights / GSC / CrUX’s own dashboards:- PageSpeed Insights, paste the merchant URL; the field-data section at the top shows origin-level p75 LCP under the “Largest Contentful Paint” panel.
- Google Search Console → Core Web Vitals report, shows URL groups failing LCP threshold with affected URL counts.
- Chrome DevTools → Performance tab, for live LCP measurement during development.
- Web Vitals Chrome extension, surfaces LCP for the current page in real-time as you browse.
| Reason | Direction | What to do |
|---|---|---|
| Window timing. Vortex IQ refreshes daily; CrUX dataset publishes monthly with daily-updated rolling windows. The most recent 1-2 days may not yet reflect. | Vortex IQ lags for 1-2 days | Wait for next refresh; check last_synced_at. |
| Origin vs URL. Vortex IQ headline shows origin-level (whole site); PSI defaults to URL-level when a specific URL is queried. | Different aggregation | Use the per-URL view (psi_slowest_lcp_urls) for direct URL comparison. |
| Form factor. Vortex IQ headline defaults to mobile; PSI defaults to mobile too. | n/a if both mobile | Confirm form factor on both views. |
| CrUX dataset version. Google publishes new CrUX data monthly. The dataset transition (typically second Tuesday of the month) can produce step changes that look like anomalies but are dataset boundary effects. | Either direction | Acknowledge the monthly boundary; trends spanning the boundary should be read carefully. |
| Comparison | Expected relationship | When divergence is legitimate |
|---|---|---|
crux_lcp_p75 ↔ psi_lab_lcp | Field and lab directionally agree | Persistent gaps (lab fast, field slow) suggest real users on slower hardware/networks than lab emulation. |
crux_lcp_p75 ↔ Internal RUM tools (Datadog RUM, New Relic Browser, SpeedCurve) | Should align within 200-500ms p75 | Internal RUM samples your traffic directly; CrUX samples opted-in Chrome users. Cohort differences explain modest divergence. |
crux_lcp_p75 ↔ GA4 ga_bounce_by_device | Inverse correlation | LCP slowness predicts bounce rate; brands optimising LCP should see bounce rate drop on the same device profile within 4-8 weeks. |
Known limitations / merchant FAQs
My LCP is at 4.2 seconds. How fast can I get to under 2.5 seconds? Depends on the underlying issue. For the typical Stencil-themed BC site with hero-image-driven LCP, expect 4-8 weeks of focused work to move from 4.2s → 2.4s, including: image format conversion (saves 800-1500ms), CSS critical-path optimisation (saves 200-500ms), third-party script deferral (saves 200-600ms), CDN cache tuning (saves 100-300ms). Reaching under 2.5s on mobile p75 is achievable for almost all sites; reaching under 2.0s requires architectural-level work (server-side rendering, edge functions, image-CDN integration). Why does my LCP keep regressing after I fix it? Common causes. (1) New marketing tags get added via Google Tag Manager without the marketing team realising the performance cost; the tag-manager bundle bloats over time. (2) Theme updates introduce new render-blocking resources; theme version bumps occasionally add stylesheet imports. (3) Hero image gets replaced with a higher-resolution version during a campaign; the merchant team doesn’t always re-optimise. (4) Third-party widgets update: Klaviyo, chat widgets, A/B testing tools all push new versions that may load differently. Defence against regression: add LCP threshold to your CI/CD pipeline (Lighthouse-CI), block deploys that regress LCP by more than 200ms. My desktop LCP is 1.5s but mobile is 4.2s. Should I worry about mobile? Yes. Google indexes mobile-first; mobile traffic is typically 60-80 percent of ecommerce volume; mobile users on slow networks are more sensitive to load delays. Mobile is the priority. The desktop fast time can mask a mobile problem; brands that report only desktop numbers to leadership are making the metric look healthier than reality. Why is the LCP element my hero image instead of my logo? LCP is calculated as the largest above-the-fold element by render area. Your logo is small; your hero image is large; the hero image gets selected. This is correct behaviour: large elements take longer to render and dominate the perceived load experience. Optimising the LCP element (the hero image) is the right work even if it feels counterintuitive. My LCP is fast on my own connection but PSI says it’s slow. Why? Your connection is faster than the emulated 4G that PSI uses. Lighthouse’s mobile profile applies “Slow 4G” throttling (1.6 Mbps down, 750 Kbps up, 150 ms RTT) which more than doubles load times vs typical office wifi. This is by design: PSI emulates “real-world mobile users on imperfect networks” rather than “developer on fast wifi”. Your subjective experience is not the truth source; the field-data CrUX measurement is what real users experience. Should I optimise images at the CDN layer or pre-build them? Both. Pre-built optimised assets (WebP at 80 quality, properly dimensioned for mobile) cover the bulk of cases; CDN-layer optimisation (Cloudinary, imgix, Shopify Images CDN, BC’s image CDN) handles dynamic resizing and format negotiation. The combination produces the best results: pre-built assets cover the static catalog, CDN handles user-uploaded content and per-device variants. My LCP improved in lab but field is still slow. What’s wrong? Three possibilities. (1) CDN caching isn’t warm yet: lab requests benefit from Google’s PSI infrastructure being well-warmed; real-user requests hit cold cache more often. (2) Real-user audience is on slower devices than lab emulation assumes: heavy international or low-income share. (3) The 28-day window hasn’t fully absorbed the fix yet: lab measures the moment-of-deploy state; field is a 28-day rolling average. The first explanation is the most common; verify CDN cache hit rates after deploys. Can Vortex IQ tell me which specific image to optimise? Yes, viapsi_image_optimisation. The card surfaces oversized images per page with byte-savings estimates, ranked by impact. Combined with psi_slowest_lcp_urls (which identifies the worst-LCP URLs), you can pinpoint the specific image-and-page combination contributing most to LCP failures.
My BC store is on Stencil. Should I migrate to Catalyst for LCP improvement alone?
Probably not as the sole reason. Catalyst’s structurally better performance (server-side rendering, automatic image optimisation, code-splitting) typically saves 500-1500ms of mobile LCP without merchant-side optimisation work, but a well-optimised Stencil site can match or exceed a default-config Catalyst site. Migrate to Catalyst for the broader benefits (multi-language via GraphQL, modern dev velocity, headless flexibility); LCP improvement is one of several reasons rather than the standalone justification. Brands at 4.2s LCP on Stencil that can’t justify migration should still be able to reach 2.5s with focused optimisation work.
Can I just preload everything to make LCP fast?
Counterintuitively, no. Preloading too many resources delays the network priority queue for the truly-critical assets and can make LCP worse. Preload sparingly: the LCP image and any critical CSS, that’s it. Anything else should load with normal priority or be deferred entirely.
Does AMP help LCP?
Marginally for some sites; not enough to justify AMP’s other costs (forked codebase, design constraints, Google Cache complexity). AMP usage has been declining since Google removed AMP-specific ranking benefits in 2021. Modern alternatives (Astro, Next.js with proper image optimisation, BC Catalyst) achieve AMP-like performance without the constraints.