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.
| What it counts | Lab LCP measurement for each template’s representative URL. Reported per template with traffic share weighting. Mobile profile by default. |
| Sample type | Lab data from per-template Lighthouse audits. Field equivalent: crux_lcp_p75 at origin level (per-URL field via psi_slowest_lcp_urls). |
| Why per-template LCP matters | LCP varies dramatically by template type. Homepage carousels select different LCP elements than PDP product images than collection grid first-images. Each template’s LCP traces to a specific element, and template-level fixes ship to many URLs at once. |
| Common per-template LCP patterns | (1) Homepage: hero carousel image (large, often unoptimised). (2) PDP: product hero image (variable per product). (3) Collection: first product image in the grid. (4) Cart, checkout: lighter pages, faster LCP, usually no work needed. (5) Search: first result’s image, similar to collection pattern. |
| Reading the per-template view | Sort by LCP × traffic share. Identify which template carries the worst LCP × highest traffic. Apply template-level image fix-pattern: responsive variants, format conversion, preload. One fix lifts all URLs in the template. |
| Currency | n/a, milliseconds per template. |
| Time window | T/7D |
| Alert trigger | worst-template LCP > 4,000ms (poor band on dominant template). |
| 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, per-template LCP Wednesday 15 May 26.| Template | Mobile LCP | Traffic share | LCP × traffic | LCP element | Fix pattern |
|---|---|---|---|---|---|
| Homepage | 4,820ms | 22% | 1,060 | Hero PNG carousel slide 1 (2.8MB) | Format + responsive variants |
| Collection page | 4,610ms | 28% | 1,290 | First product image in 12-grid | Lazy-load grid + format conversion |
| Product detail page | 3,640ms | 25% | 910 | Product hero image (1.6MB JPEG) | Format conversion + preload |
| Search results | 4,200ms | 8% | 336 | First result image | Same as collection |
| Cart | 2,180ms | 8% | 174 | (light page, no media drag) | None |
| Checkout step 1 | 1,940ms | 4% | 78 | (lightest) | None |
| About / contact | 3,420ms | 1% | 34 | Banner image | Low priority |
- 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.
| Time horizon | Action |
|---|---|
| First 1 hour | Identify worst-LCP × traffic templates. |
| First week | Apply image format + responsive variants on the top template. |
| Day 28 | Field LCP via crux_lcp_p75 reflects template fixes. |
Sibling cards merchants should reference together
| Card | Why merchants reach for it |
|---|---|
psi_score_by_template | Composite score per template. |
psi_cwv_pass_by_template | All-3 pass rate per template. |
psi_opportunity_by_template | Optimisation opportunities per template. |
psi_slowest_template | Worst template singled out. |
psi_template_trend | Per-template trend over time. |
crux_lcp_p75 | Field LCP at origin level. |
psi_slowest_lcp_urls | Per-URL LCP ranking. |
psi_image_optimisation | Common LCP fix lever. |
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.
| Reason | Direction | What to do |
|---|---|---|
| Template classification. Vortex IQ uses URL-pattern + GA4 + theme metadata. | Variable | Confirm template-to-URL mapping. |
| Run-to-run variance. ±10-20% per measurement. | Either direction | Use 7-day rolling. |
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.