At a glance
Single-line callout: which template is the slowest right now? Reduces the per-template performance score across all templates to one answer: the worst-performing template by Lighthouse Performance Score (with LCP-p75 used as a tiebreaker if multiple templates share the same score). This is the “where do I focus” answer in one sentence: when a merchant has 7 templates and limited engineering bandwidth, the slowest template is where the next sprint earns the most uplift per hour invested.
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, slowest template Wednesday 15 May 26.
Slowest template: Collection page (score 41, LCP-p75 4.6s, INP-p75 280ms, CLS-p75 0.18, failing on all three Core Web Vitals).
What the slowest-template answer is telling us:
- Collection pages are the bottleneck. Score 41 sits in the “poor” red zone. LCP, INP, and CLS are all in the failing range simultaneously. No other template is in this state, every other template scores 64+ with at least 2 of 3 CWV passing.
- Why collection is slow, in priority order: (a) LCP-p75 4.6s, heavy image grid loads above-the-fold without prioritisation; (b) INP-p75 280ms, filter widget JS blocks main thread on every interaction; (c) CLS-p75 0.18, lazy-loaded images cause layout shifts as they pop in.
- Why this matters commercially. Collection pages are the discovery layer between homepage and PDP. Fashion shoppers spend the longest on collection pages browsing inventory. A 4.6s LCP on collection means typical shoppers wait nearly 5 seconds for the grid to render, with many bouncing or refining back to homepage. Conversion rate on collection-entry sessions is materially below average for this merchant (this can be confirmed via GA4 funnel analysis, which is what slowest-template handoffs to).
-
The single-template ship plan for the next sprint:
- Day 1-3: Image work on collection, responsive variants, format conversion (WebP/AVIF), priority hint on the first row of cards.
- Day 4-7: Filter widget JS audit, defer or async-load, remove unused dependencies, code-split per filter type.
- Day 8-10: Reserve image dimensions + lazy-load with placeholder boxes to remove CLS.
- Day 11-14: Re-audit, confirm score lifts above 60, LCP-p75 below 2.5s.
- Expected uplift. Score moves from 41 → 65+ in two weeks of focused collection work. LCP-p75 drops from 4.6s to under 2.5s. CWV pass rate on collection moves from “failing” to “passing.” Site-wide score uplift follows because collection traffic is a large share of pageviews.
- What we are NOT doing this sprint. Homepage (score 72), PDP (score 68), checkout (score 86), none get touched. Capacity is finite and collection has the most pain × the highest leverage. Single-template focus beats spread-across-7-templates every time when bandwidth is constrained.
- Read the slowest-template name and score. Single line answer to “where do we focus.”
- Cross-reference per-template LCP/INP/CLS to identify the dominant CWV failure.
- Open the opportunity list filtered to that template to see the fix sequence.
- Re-audit after each ship to confirm the slowest-template name has changed.
Sibling cards merchants should reference together
Reconciling against the vendor’s own dashboard
Where to look:- PageSpeed Insights, run a Lighthouse audit on each representative URL per template; rank manually by score.
- Search Console, Page Experience report flags the worst-performing page groups (this is template-adjacent but uses URL groupings, not Vortex IQ’s template classification).
Cross-connector reconciliation: primarily internal (with
psi_score_by_template, psi_lcp_by_template, psi_cwv_pass_by_template).
Quick rule for support tickets: when the slowest-template answer surprises a merchant, confirm template classification first (homepage URLs landing in “other”; PDP regex misclassifying), then confirm the score has been recomputed in the last 7 days.
Known limitations / merchant FAQs
Q: Why does this card show one template name when we have 7 templates with varying scores? By design. The slowest-template answer is intentionally a single line, the goal is to remove decision overhead. Merchants with limited engineering bandwidth need an unambiguous answer to “what do we work on this sprint.” If you want the full table, openpsi_score_by_template for the per-template ranking.
Q: What if two templates tie on Lighthouse score?
The card uses LCP-p75 as a tiebreaker, the template with the higher (worse) LCP-p75 wins the slowest title. If LCP also ties (rare), INP-p75 is the second tiebreaker. The tiebreaker logic is explicit so the answer is reproducible run-to-run.
Q: Our slowest template was homepage last week and PDP this week. Did we just shift the bottleneck?
Often yes. When you fix the slowest template, the next-worst template inherits the title. This is healthy behaviour, it means the previous focus paid off and the next focus is now identified. Track psi_template_trend to confirm the previous slowest template is genuinely improving (not just being overtaken by a regression elsewhere).
Q: Checkout always scores well and never appears as the slowest. Should we audit it anyway?
Probably not. Platform checkouts (Shopify, BigCommerce, Adobe Commerce) are pre-optimised and rarely surface as the bottleneck. Effort spent there is low-leverage. Stay on the actual slowest template until its score lifts above the alert threshold.
Q: The slowest template alert fired (score < 40). Is that a release regression or chronic baseline?
Check psi_template_trend for that template’s last 30-90 days. If the score dropped suddenly within the last 7 days, it’s a release regression, bisect commits, find the offending change. If the score has sat below 40 for 30+ days, it’s chronic baseline, the template needs a planned refactor sprint, not a hotfix.
Q: Can the slowest-template answer be wrong because the audit URL isn’t representative?
Yes, and this is the most common source of disputes. Each template uses one representative URL for the lab audit. If that URL is unusually heavy (a flagship product PDP) or unusually light (the simplest collection), the score may not reflect typical experience. Cross-check by sampling 3-5 URLs per template manually; if the spread is wide, the audit URL config needs updating.
Q: How does this card differ from psi_score_by_template?
psi_score_by_template shows all templates with their scores in a table, read it when you want the full picture. This card collapses that table to “the worst one”, read it when you need the answer in one sentence. The two cards are designed to be used together: this card for the headline, the table card for the detail.