At a glance
LCP broken down by page template, surfaces which templates have the worst load speed. Most ecommerce LCP issues concentrate on a small set of templates (homepage hero, PDP hero, collection grid first-image), so the per-template view directly identifies the optimisation focus. Pairs with psi_score_by_template for the full picture; this card decomposes the LCP sub-metric specifically.
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, per-template LCP Wednesday 15 May 26.
What the per-template view is telling us:
- Collection page (1,290) tops the priority ranking. 4,610ms LCP × 28% traffic share = highest commercial impact. The first product image in the 12-grid is the LCP element; lazy-loading images 5-12 + format conversion drops the metric significantly.
-
Homepage (1,060) is second priority. Same image-driven LCP issue with the hero carousel. Same fix-pattern: WebP/AVIF format + responsive variants via
srcset. - PDP (910) is third priority. 78 product detail pages share the same template; one PDP template fix lifts all 78 simultaneously. Most leverage of any single template fix on the site.
- Search results (336) shares fix-pattern with collection, same image-grid approach. Tackle alongside collection if the same code is shared.
- Cart, checkout, about, account: low priority. Healthy LCP or low traffic; no active work.
-
Template-level fix sequence:
- Week 1: Collection template (covers ~12 collection pages + search results + visually similar tail). Single template fix lifts all simultaneously.
- Week 2: Homepage hero carousel.
- Week 3-4: PDP template (covers all 78 PDPs).
-
Realistic post-fix LCP forecast:
- Collection: 4,610ms → 2,200ms
- Homepage: 4,820ms → 2,400ms
- PDP: 3,640ms → 2,100ms
- Site-weighted LCP: from 3,920ms toward 2,400ms (good band)
- Sort templates by LCP × traffic share.
- Identify each template’s LCP element via Lighthouse audit JSON.
- Apply template-level image fix-pattern as primary lever.
- Re-audit each template after fix to confirm LCP dropped.
Sibling cards merchants should reference together
Reconciling against the vendor’s own dashboard
Where to look:- PageSpeed Insights, paste each template’s representative URL.
- GSC URL Inspection tool, for individual URL field-data.
Cross-connector reconciliation: primarily internal (with the LCP-related cards and per-template cards).
Quick rule for support tickets: if a template’s LCP is high, it’s almost always image-driven. Check the LCP element via Lighthouse audit JSON and apply image fix patterns.
Known limitations / merchant FAQs
Why does PDP have variable LCP across products? Different product images. Each PDP renders a different hero image; image quality / size varies by product. The template’s representative URL is one specific PDP; the per-template LCP shown is for that URL. Cross-referencepsi_slowest_lcp_urls for per-URL detail across all PDPs.
My collection page LCP fixes haven’t moved the field metric. Why?
Lab measures one URL; field measures all collection-page URLs. Maybe one collection page got fixed but the other 11 didn’t. Template-level fixes propagate to all template URLs, but if the deploy was URL-specific (e.g. only the test page), only that URL improves.
Should I optimise the homepage LCP element or the homepage page weight?
Both, in sequence. LCP fix first: convert hero image format, add preload. Then total page weight reduction (image variants + JS deferral). LCP fix has narrow but big-impact; weight reduction has broad smaller impact across many sub-metrics.
Can I lazy-load the LCP image?
No, that breaks LCP entirely (it would load lazily, after first paint). The LCP image should have loading="eager" and <link rel="preload">. Lazy-load applies to BELOW-the-fold images.