At a glance
Ranked list of optimisation opportunities, sorted by estimated milliseconds saved if applied. Lighthouse identifies dozens of audit categories (eliminate render-blocking resources, properly size images, defer offscreen images, minify CSS, enable text compression, reduce unused JS, serve modern image formats, etc.) and quantifies the time savings each would deliver if implemented. The single most actionable card in the website_performance set: instead of “your site is slow”, it gives you a ranked todo list with quantified payoff per item. Tackling the top 3 opportunities typically delivers 60-80 percent of the total available improvement; the long tail of small opportunities offers diminishing returns.
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 homepage, mobile audit, Wednesday 15 May 26.
What the ranked list is telling us:
-
Opportunities 1 + 2 (image sizing + format) cumulatively deliver 2,760ms of estimated savings, 64 percent of the total available improvement. Both touch the same 4 hero PNGs; the fix is a single workflow: convert to WebP, serve responsive variants via
srcset. One coordinated effort delivers two opportunities at once. Realistic ship time: 1-2 days of focused work for a developer familiar with BC theme structure. - Opportunities 1, 2, 3 cumulatively deliver 3,240ms, 75 percent of total savings. Adding the render-blocking-CSS fix (inline critical CSS, defer non-critical) is another 0.5-1 day of work. The first 75 percent of improvement takes ~3 days of focused work.
- Opportunities 4 + 5 deliver another 600ms but are more invasive. Reducing unused JS requires actual code changes (removing jQuery dependencies; auditing GTM tags); deferring offscreen images requires touching every collection-page template. Plan for week 2 of optimisation work.
- Opportunities 6-9 are polish. Combined ~460ms; worth doing but not urgent. Move to week 3 or later.
- The “80-20 rule” applies cleanly here. Top 3 = 75 percent of value; top 5 = 89 percent; the long tail of opportunities 6-9 is 11 percent of value but the same ratio of effort.
- Implementation discipline matters. Don’t batch all 9 opportunities into one deploy; ship one at a time and re-measure. Each fix’s actual impact varies from the estimate, and stacking changes makes attribution impossible. The right rhythm: ship opportunity 1, wait 7 days, re-audit, ship opportunity 2, repeat.
- The ranking can change between audits. Once you fix opportunity 1, opportunity 2’s estimate may shift (the percentages re-balance against the new baseline). Re-rank before each ship; don’t blindly follow the original list to position 9.
- Read the top 3 carefully. The Lighthouse audit JSON includes
description,displayValue, and per-resourcedetails. Understanding why an opportunity exists matters more than blindly applying the fix. - Verify with developer tools. Chrome DevTools Coverage tab confirms unused-CSS and unused-JS findings; Network tab confirms transfer size opportunities; Performance tab confirms render-blocking and TBT opportunities.
- Ship one at a time. Re-audit after each ship to measure actual impact and re-rank remaining opportunities.
- Don’t chase the long tail. Opportunities below 100ms savings rarely justify the engineering effort.
Sibling cards merchants should reference together
Reconciling against the vendor’s own dashboard
Where to look in PageSpeed Insights’ own dashboard:- PageSpeed Insights, the “Opportunities” section near the bottom of the report shows the same ranked list with full per-resource detail.
- Chrome DevTools → Lighthouse panel, runs the same audit locally; opportunity output matches PSI within run-to-run variance.
- Lighthouse CI (github.com/GoogleChrome/lighthouse-ci), runs Lighthouse in your build pipeline; can fail builds when new opportunities exceed a threshold.
Cross-connector reconciliation:
Quick rule for support tickets: if a merchant says “I shipped opportunity 1 but the score didn’t improve as estimated”, the most common cause is partial implementation (image format converted but responsive variants missing; render-blocking fix only on homepage but not collections). Re-audit and check whether the opportunity still appears in the list; if it does, the implementation is incomplete.
Known limitations / merchant FAQs
The same opportunity keeps appearing after I think I fixed it. Why? Three common causes. (1) Partial implementation: you fixed it on one template (homepage) but not others (collections, PDPs); the audit sees the unfixed templates and re-flags. (2) Cache invalidation lag: the fix deployed to origin but CDN is serving stale cached resources; wait for cache TTL or manually purge. (3) Misidentified resource: Lighthouse’s resource attribution can occasionally misidentify which file is the issue; the fix targeted the wrong resource. Cross-reference with DevTools to confirm. Should I implement all opportunities Lighthouse identifies? No. Implement the top 3 first; measure impact; reassess. The long tail of small opportunities (under 100ms savings each) typically isn’t worth the engineering effort. An exception: if you’re trying to push from a passing-but-mediocre score (60-70) to excellent (85+), the long tail matters because each percentage point at the top requires more effort. My top opportunity says “save 1.2s” but I shipped the fix and only saw 0.6s improvement. Why? Lighthouse savings estimates are directional, not precise. Real-world implementation typically delivers 50-80 percent of the estimated savings due to: (a) implementation imperfections; (b) interactions with other resources; (c) measurement variance. 0.6s on a 1.2s estimate is normal; if the actual savings was 0.1s on a 1.2s estimate, the implementation is incomplete. Why does Lighthouse not surface my biggest pain point? Lighthouse audits a fixed catalogue of opportunities. If your specific issue isn’t in the catalogue (e.g. business-logic-heavy page rendering server-side, custom A/B testing variants, slow third-party API calls), Lighthouse may not flag it. Use Chrome DevTools Performance panel for issues outside Lighthouse’s catalogue. Can I get an opportunity for fixing TTFB? Yes, “Reduce server response times (TTFB)” is one of the standard opportunities. It surfaces when TTFB exceeds 600ms; the implementation guidance is generic (faster server, better CDN, cache more), but the metric tracking confirms whether the fix worked. What if my top opportunity is “Avoid enormous network payloads”? That’s a catch-all that typically appears when total page weight exceeds 3MB. The actionable fix isn’t the opportunity itself; it’s identifying which specific resources contribute most. Cross-reference withpsi_total_weight and psi_image_optimisation for the per-resource detail.
Can Vortex IQ create Kanban tasks from these opportunities automatically?
Yes, via the Vortex Mind Pre-Launch Readiness report. The report converts top-N opportunities into Kanban cards under the Performance swimlane with: title, description, estimated savings, affected resources, recommended fix. The merchant’s developer or agency picks them up.
My BC site is on Catalyst. Are the opportunities different?
Mostly the same (Lighthouse audits are platform-agnostic), but the typical ranking shifts. Catalyst sites often have render-blocking-CSS lower-ranked because Next.js handles critical CSS automatically; image opportunities are lower-ranked because next/image handles formats; JS opportunities are higher-ranked because Catalyst applications can have larger client-side bundles than Stencil if not code-split properly.
Should I run audits on every page or just the homepage?
Multiple pages. The homepage often has different opportunities than PDPs, which differ from collection pages. Recommended audit scope: homepage, top 3 PDPs by traffic, top 2 collection pages, cart, checkout. The Vortex IQ integration captures this set automatically.
My audits run weekly but my devs ship daily. Is that fast enough?
Probably not for active optimisation work. Switch to daily audits during optimisation cycles so you can attribute changes to specific deploys. After the optimisation cycle ends and you’re in monitoring mode, weekly is sufficient.