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.
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.
What the per-template view is telling us:
- 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.
Sibling cards merchants should reference together
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.
Cross-connector reconciliation:
Quick rule for support tickets: if a merchant says “PSI shows my LCP at 2.8s but your card shows 3.4s”, the most common cause is form factor mismatch (PSI desktop tab vs Vortex IQ mobile default) or origin-vs-URL mismatch (PSI was run on a fast page, Vortex IQ shows origin-aggregate). Confirm form factor + aggregation level; the metrics should match within 200ms.
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.