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.
| What it counts | The template name (homepage, PDP, collection, cart, checkout, search, about/contact, etc.) with the lowest Lighthouse Performance Score from the latest per-template audit cycle. Reported as a single text label with the score and LCP-p75 alongside. |
| Sample type | Lab data from per-template Lighthouse audits (one representative URL per template). |
| Why “slowest template” matters | Without this distillation, merchants stare at 7 score values and pick a focus by gut feel. The slowest template is the answer in plain English: “this week, fix collection pages.” Removes ambiguity about where the next investment should land. |
| Reading the answer | (1) Note the template name. (2) Note the score, used to gauge severity (sub-50 critical, 50-69 poor, 70+ moderate). (3) Cross-reference psi_lcp_by_template to see whether LCP, INP, CLS, or weight is the dominant pain point on that template. (4) Open psi_opportunity_by_template filtered to that template to see the prioritised fix list. |
| Currency | n/a, text label. |
| Time window | T/7D (last per-audit cycle). |
| Alert trigger | slowest-template-score < 40 (severe critical-template regression, the slowest template is now in red zone). |
| Sentiment key | null (text answer; sentiment driven by score). |
| Roles | owner, 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, slowest template Wednesday 15 May 26.| Template | Lighthouse score (mobile) | LCP-p75 (s) | INP-p75 (ms) | CLS-p75 | Notes |
|---|---|---|---|---|---|
| Homepage | 72 | 2.8 | 180 | 0.06 | Heavy hero, large carousel |
| Product detail page | 68 | 3.2 | 220 | 0.04 | Image stack + reviews widget |
| Collection page | 41 | 4.6 | 280 | 0.18 | ← slowest |
| Cart | 78 | 1.8 | 120 | 0.02 | Lean |
| Checkout | 86 | 1.4 | 90 | 0.01 | Platform-optimised |
| Search | 64 | 3.1 | 240 | 0.09 | Result grid heavy |
| About / contact | 82 | 1.9 | 110 | 0.03 | Lightest |
- 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.
| Time horizon | Action |
|---|---|
| First 1 hour | Read the slowest-template answer. Confirm severity via score. |
| First day | Open psi_opportunity_by_template filtered to that template. |
| First week | Ship the highest-leverage fix on that template. |
| Re-audit | Confirm slowest-template has shifted (or score has lifted above the alert threshold). |
Sibling cards merchants should reference together
| Card | Why merchants reach for it |
|---|---|
psi_score_by_template | Full per-template score table; this card surfaces the worst entry. |
psi_lcp_by_template | LCP per template; identifies whether LCP drives the slowest template. |
psi_cwv_pass_by_template | All-3 CWV pass per template; binary pass/fail view. |
psi_opportunity_by_template | Per-template opportunity list; opens the fix sequence for the slowest template. |
psi_template_trend | Per-template historic trend; shows whether the slowest template is degrading or stable. |
psi_perf_score_summary | Site-wide score; gives the average against which the slowest template compares. |
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).
| Reason | Direction | What to do |
|---|---|---|
| Template classification. Vortex IQ uses URL pattern + GA4 page_path + theme metadata to group URLs into templates. Manual checks compare individual URLs, not templates. | Variable | Confirm template-to-URL mapping in the audit configuration. |
| Tiebreaker logic. When two templates share the same Lighthouse score, Vortex IQ tiebreaks on LCP-p75 (slower LCP wins). Manual ranking may use different tiebreakers. | Variable | Use the score + LCP-p75 pair to confirm. |
| Audit cadence. Vortex IQ audits per template on a fixed schedule. A manual run between cycles may show a different worst template due to natural variance. | Either direction | Use 7-day rolling. |
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.