At a glance
Lighthouse optimisation opportunities broken down by page template, surfaces which specific opportunities apply to which templates. Different templates have different opportunity profiles: homepage dominated by image format issues, collection by unused-JS, checkout typically clean. Per-template opportunity view enables targeted fix planning: instead of “fix images on the site”, the merchant can plan “fix images on the homepage hero, fix unused JS on collection filter widget, leave checkout untouched”.
| What it counts | Per template’s representative URL: the top Lighthouse opportunities by ms savings, with affected resources and recommended fix. Reported per template with severity. |
| Sample type | Lab data from per-template Lighthouse audits. |
| Why per-template opportunity matters | Opportunities aren’t site-wide, they’re URL-specific. Homepage may have a “properly size images” opportunity that PDPs don’t have, because the hero images are different. The per-template view targets fixes precisely. |
| Reading the per-template view | (1) Identify which template has the most opportunities × highest savings. (2) Prioritise fixes that affect multiple templates simultaneously (e.g. theme bundle JS unused affects all templates). (3) Use the top-3 opportunities per template as the fix-ship order for that template. |
| Currency | n/a, opportunity list per template. |
| Time window | T/7D (per-audit). |
| Alert trigger | top opportunity in any template > 1,500ms savings (large fix opportunity available). |
| Sentiment key | null (list view). |
| 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, top opportunities per template Wednesday 15 May 26.| Template | Top opportunity | ms saved | Second opportunity | ms saved | Shared with other templates |
|---|---|---|---|---|---|
| Homepage | Properly size images (4 hero PNGs) | 1,840 | Eliminate render-blocking (theme CSS) | 480 | Theme CSS shared with all |
| Product detail page | Properly size images (product hero) | 1,200 | Reduce unused JS (jQuery, GTM) | 320 | jQuery + GTM shared with all |
| Collection page | Defer offscreen images (lazy-load grid) | 800 | Reduce unused JS (filter widget) | 280 | Filter widget collection-only |
| Cart | Reduce unused JS (cart-drawer) | 180 | (no other significant opportunity) | - | Cart-drawer JS shared with PDP |
| Checkout | (no significant opportunities, healthy) | - | - | - | n/a |
| Search | Defer offscreen images (results grid) | 480 | (light backend, minor opportunities) | - | Same fix as collection |
| About / contact | Properly size images (banner) | 320 | (lightest pages) | - | Same fix-pattern as hero |
- Image-related opportunities span 5 of 7 templates. Homepage, PDP, collection, search, about, all have image fix opportunities ranking #1-2. A coordinated image optimisation cycle (responsive variants + format conversion across the merchant’s image library) addresses 5 templates simultaneously.
- Render-blocking + unused JS opportunities are theme-wide. Theme CSS bundle, jQuery, GTM container appear across multiple templates. Fixing these once via theme-level changes shows up as opportunities-resolved across templates simultaneously.
- Template-specific opportunities exist alongside shared ones. Collection’s filter widget JS is collection-only; cart-drawer JS is cart + PDP. Plan fix sequence: shared opportunities first (theme-level), then template-specific.
- Checkout has no significant opportunities. Already lean; no work needed. Don’t optimise when the audit says nothing meaningful is available.
-
Recommended ship sequence:
- Week 1: Image format conversion + responsive variants (covers homepage, PDP, collection, search, about, 5 of 7 templates)
- Week 2: Theme CSS render-blocking fix (covers all templates)
- Week 3: Theme JS unused removal, jQuery audit, GTM tag cleanup (covers all templates)
- Week 4: Collection filter widget refactor (collection-only)
- Week 5: Cart-drawer refactor (cart + PDP)
- Result: top opportunities resolved across all templates; site-wide score uplift
- Cumulative ms savings forecast: weeks 1-2 deliver the largest single uplift (3,000+ms savings across templates); weeks 3-5 deliver the long tail of incremental improvements.
- Sort opportunities by ms saved × templates affected. Shared-template opportunities are highest leverage.
- Plan fix sequence: shared first, template-specific second.
- Re-audit per template after each ship to confirm opportunity resolution.
| Time horizon | Action |
|---|---|
| First 1 hour | Identify shared opportunities across templates. |
| First week | Apply highest-leverage shared fix (typically image work). |
| Day 14 | Address template-specific opportunities. |
| Re-audit | Confirm opportunities resolved. |
Sibling cards merchants should reference together
| Card | Why merchants reach for it |
|---|---|
psi_top_opportunities_ms | Site-wide opportunities; this card decomposes by template. |
psi_top_opportunities_bytes | Bytes-savings ranking. |
psi_score_by_template | Score per template. |
psi_lcp_by_template | LCP per template. |
psi_cwv_pass_by_template | All-3 pass per template. |
psi_image_optimisation | Image-specific opportunities. |
psi_unused_js | JS-specific opportunities. |
psi_unused_css | CSS-specific opportunities. |
Reconciling against the vendor’s own dashboard
Where to look:- PageSpeed Insights, opportunities section per URL.
- Lighthouse audit JSON, per-URL opportunities; assemble per-template view manually.
| 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. Opportunity savings estimates fluctuate ±10-20%. | Either direction | Use 7-day rolling. |
Known limitations / merchant FAQs
Q: We see five different opportunities flagged on the homepage. Which do we ship first? Sort by ms-saved × number-of-templates-affected. An opportunity that saves 1,200ms on the homepage alone ranks below an opportunity that saves 600ms across five templates simultaneously. The per-template view exists precisely to surface these cross-template wins. Theme-level fixes (CSS, JS bundle, image library) almost always beat template-specific fixes on aggregate uplift. Q: Two of our top opportunities are “reduce unused JS” on the homepage and on the PDP. Are those the same fix or different? Open each opportunity row and check the affected resources column. If the unused-JS line items reference the same script URLs (theme.js, vendor bundle, GTM container), it’s one fix that resolves both rows. If the resources are different (homepage hero carousel JS vs. PDP review-widget JS), they’re two distinct ships. The diagnostic flow always starts with “are these the same resource.” Q: Checkout shows zero opportunities. Is the audit broken? Almost never. Checkout templates on Shopify, BigCommerce, and Adobe Commerce are typically pre-optimised by the platform itself, with minimal merchant-controlled JS or images. A clean checkout audit is the expected outcome. Verify the URL audited is actually a checkout step (sometimes the audit lands on a cart page mislabelled as checkout) before assuming the data is wrong. Q: Same opportunity (“eliminate render-blocking resources”) shows on every template with different ms-savings. Why? The opportunity is the same theme-level resource (typically a render-blocking CSS file in the head), but the savings vary because each template renders different above-the-fold content. Pages with heavier hero content (homepage, PDP) feel the render-blocking pain more, so the savings are higher there. Fix once at the theme layer, all templates benefit, magnitude varies. Q: We applied a fix and the next audit still shows the same opportunity. Did the fix not land? Three checks before assuming the fix failed. (1) Confirm the deploy reached production and the audit URL points at production, not staging. (2) Compare the affected-resources list before and after; if the same resource still appears, the fix didn’t propagate. If different resources now appear, the fix worked but other resources have surfaced. (3) Wait for the next audit cycle, since opportunities are recomputed each run and small variance (±10-20%) means a marginal fix may still appear briefly. Q: How does this card differ frompsi_top_opportunities_ms?
psi_top_opportunities_ms is the site-wide ranked list, the single highest-savings opportunity overall. This card decomposes that list per template, exposing where each opportunity actually applies. Use the site-wide card for “what’s the biggest fix on this site.” Use the per-template card for “where do we ship the fix and which templates does it touch.”
Q: Should we worry about template-specific opportunities that only affect one template?
Only after shared opportunities are resolved. Template-specific opportunities are real, but the leverage is lower. Ship the theme-level shared fixes first; revisit template-specific items in a later sprint. Exception: if a single-template opportunity sits on a high-revenue template (PDP, checkout) with large ms-savings, prioritise it earlier in the sequence.