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.
| What it counts | The list of Lighthouse “Opportunity” audits that surfaced a non-zero wastedMs in the most recent audit run, sorted descending by estimated milliseconds saved. Each opportunity carries: title, estimated savings (ms), affected resources (URLs and bytes), implementation guidance. |
| The opportunity categories | Lighthouse identifies these (non-exhaustive): (1) Eliminate render-blocking resources (CSS/JS in <head> blocking first paint). (2) Properly size images (serving 1200x800 image displayed at 400x300). (3) Defer offscreen images (lazy-load below-fold content). (4) Reduce unused CSS (CSS rules not applied to current page). (5) Reduce unused JavaScript (JS not executed during page load). (6) Serve images in next-gen formats (PNG/JPEG → WebP/AVIF). (7) Enable text compression (gzip/brotli on text resources). (8) Preconnect to required origins (warm up DNS + TLS for critical third parties). (9) Avoid enormous network payloads (catch-all weight check). (10) Reduce server response times (TTFB). |
| Estimated savings | Lighthouse uses a scoring model to estimate the millisecond improvement if the opportunity is implemented. The estimates are directional rather than precise: an opportunity claiming “saves 1.2s” typically delivers 0.6-1.4s in real-world implementation. Treat the rankings as priority order, not absolute savings predictions. |
| Sample type | Lab data from a single Lighthouse audit. Re-runs may surface different opportunities depending on what’s currently slow. |
| Device profile | Mobile by default (slow 4G + mid-tier hardware). Desktop typically surfaces fewer or smaller opportunities. |
| What’s NOT in this card | Opportunities below Lighthouse’s threshold (typically savings under ~50ms) are dropped. They’re real opportunities but the marginal cost of implementing them outweighs the benefit. The threshold prevents the list from being a 50-item long-tail of micro-optimisations. |
| The 80-20 rule | The top 3 opportunities typically deliver 60-80 percent of the total available time savings. The middle band (opportunities 4-7) delivers another 15-25 percent. The long tail (8+) is usually under 5 percent and not worth chasing. Ship the top 3 in week 1; reassess after measuring impact. |
| What an “opportunity” is not | These are Lighthouse-identified categories, not custom recommendations. The audit surfaces what’s slow; it doesn’t know your business priorities. A merchant might rationally choose not to fix an opportunity (e.g. keep a 500KB hero video despite the LCP cost because it’s a brand-defining moment). The card surfaces options; the merchant decides priorities. |
| Currency | n/a, this is a duration in milliseconds. |
| Time window | T/7D (per-audit current state plus 7-day trend of total opportunity ms). |
| Alert trigger | top opportunity > 1500ms savings available (a single fixable issue worth more than 1.5 seconds; should not exist on a healthy site). |
| Sentiment key | null (this is a list, not a thresholded metric) |
| 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 homepage, mobile audit, Wednesday 15 May 26.| Rank | Opportunity | Savings (est.) | Affected resources | Cumulative savings |
|---|---|---|---|---|
| 1 | Properly size images | 1,840ms | 4 hero PNGs (2.8MB total at 1920px serving on 412px viewport) | 1,840ms |
| 2 | Serve images in next-gen formats | 920ms | Same 4 hero PNGs (could be WebP at 80 quality) | 2,760ms |
| 3 | Eliminate render-blocking resources | 480ms | Stencil theme CSS + Klaviyo external CSS in <head> | 3,240ms |
| 4 | Reduce unused JavaScript | 320ms | jQuery (84KB total, 64KB unused on this page) + GTM (140KB, 90KB unused) | 3,560ms |
| 5 | Defer offscreen images | 280ms | 8 collection-grid images below fold loading at page-load | 3,840ms |
| 6 | Preconnect to required origins | 180ms | Klaviyo, Tidio, GTM origins (3 third-party DNS lookups in critical path) | 4,020ms |
| 7 | Reduce unused CSS | 140ms | Stencil theme CSS (130KB total, 80KB unused on homepage) | 4,160ms |
| 8 | Enable text compression | 80ms | One uncompressed font subset file | 4,240ms |
| 9 | Avoid an excessive DOM size | 60ms | Hero carousel renders 4 slides with full DOM upfront | 4,300ms |
-
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.
| Time horizon | Action |
|---|---|
| First 1 hour after audit | Read the top 3 opportunities; understand their context. |
| First 24 hours | Ship opportunity 1 (typically image-related). |
| Day 7 | Re-audit. Confirm opportunity 1’s impact. Ship opportunity 2. |
| Day 14 | Ship opportunity 3. Re-audit. |
| Day 21+ | Move to opportunities 4-7 if they still rank highly; otherwise declare the optimisation cycle complete and move to monitoring. |
Sibling cards merchants should reference together
| Card | Why merchants reach for it |
|---|---|
psi_top_opportunities_bytes | Same opportunities ranked by byte savings rather than millisecond savings. Useful when the constraint is data plan / mobile network rather than time. |
psi_image_optimisation | Image-specific opportunities only. Drill-down for the most common top-rank opportunity. |
psi_unused_js | Unused JavaScript opportunities. |
psi_unused_css | Unused CSS opportunities. |
psi_render_blocking | Render-blocking resources opportunity. |
psi_caching_opportunities | Caching opportunities (cache-control headers, service workers). |
psi_third_party_cost | Third-party script cost. Often the underlying cause of multiple ranked opportunities. |
psi_perf_score_summary | Composite score; this card is the actionable companion. |
psi_total_weight | Total page weight; many opportunities reduce weight. |
crux_lcp_p75 | LCP impact validation; opportunities that promise LCP improvement should show up in this metric over the 28-day window. |
crux_inp_p75 | INP impact validation. |
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.
| Reason | Direction | What to do |
|---|---|---|
| Run-to-run variance. Lighthouse savings estimates fluctuate ±10-30 percent between runs. | Either direction | Use 7-day rolling rank stability rather than single-run rank. |
| Audit timing. Vortex IQ audits run on schedule; PSI runs on-demand. Site changes between runs alter opportunity rankings. | Either direction | If a deploy happened recently, the most-recent run reflects the new state. |
| URL set. Vortex IQ audits multiple URLs; PSI defaults to the URL pasted into the form. | Different scope | Use the same URL for direct comparison. |
| Lighthouse version. Vortex IQ pins a Lighthouse version for stability; PSI runs the latest. Major Lighthouse version updates can introduce new opportunity categories or shift rankings. | Either direction | Check Lighthouse version in audit metadata; reconcile across major version transitions. |
| Comparison | Expected relationship | When divergence is legitimate |
|---|---|---|
psi_top_opportunities_ms ↔ crux_lcp_p75 (post-fix) | Top opportunity savings should approximately match LCP improvement | Real-world LCP improvement is typically 50-80 percent of Lighthouse’s estimated savings. The estimate is directional, not absolute. |
psi_top_opportunities_ms ↔ psi_perf_score_summary (post-fix) | Score should rise by 10-20 points if top 3 opportunities are shipped | Score-rise scaling depends on which sub-metrics improve; image-format fixes lift LCP score; JS-deferral fixes lift TBT score. |
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.