At a glance
Per-image optimisation opportunities ranked by byte-savings potential. Lighthouse identifies images that are oversized for their display dimensions, served in legacy formats (PNG/JPEG when WebP/AVIF would be smaller), or shipped at higher quality than necessary. Each opportunity carries: image URL, current bytes, recommended bytes, format-conversion suggestion. The single most-impactful optimisation surface for ecommerce sites because images typically account for 40-60 percent of page weight and the fixes are mechanical (re-export at lower quality, convert format, serve responsive variants). Brands that work through this card’s top 5 entries routinely cut homepage and PDP weight by 50-65 percent.
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 audit, mobile, Wednesday 15 May 26.
What the ranked list is telling us:
-
The 4 hero carousel images dominate the savings opportunity (9,180KB combined savings, 81 percent of available image savings). All four are the same fix-pattern: PNG → WebP, serve responsive variants. One coordinated workflow handles all four: re-export from design source as WebP at quality 80 in 5 width variants (400/800/1200/1600/2000px), update the
<img srcset>declarations in the theme’s hero-carousel template. Time investment: 4-6 hours for a developer familiar with BC theme structure. - Product detail images (rank 5-6) are the second category. 360KB and 345KB savings each; with 78 PDPs in the catalogue, the cumulative savings across the full PDP set is roughly 25-30MB (multiple variants per product × 78 products). The fix is the same workflow: re-export at quality 82 + WebP + responsive variants. Best automated via the BC product-image upload pipeline so future uploads use the same settings.
- Collection banners (rank 7) and thumbnails (rank 8) add another 455KB of savings. These follow the same pattern; the work is mechanical re-processing of the existing image library.
- Logo and payment-icon SVG conversions (ranks 9-10) are the long-tail polish. SVG is the right format for any logo or icon (scales infinitely, often smaller than even compressed PNG). Cumulative savings are small but the maintenance benefit is large: SVG icons don’t need responsive variants, look sharp at all densities, and are trivially recolourable.
-
Cumulative impact: top-10 image fixes save 8,393KB. Combined with the JS deferral and font optimisation work from the
psi_top_opportunities_msranking, total page weight drops from 4,440KB to roughly 1,800KB. Mobile p75 LCP drops from 4,820ms to roughly 2,200-2,400ms, moving from “poor” to “good” CWV band. CWV pass rate over 28 days lifts from 64.8 percent to roughly 78-82 percent, crossing Google’s 75 percent threshold. Estimated organic traffic recovery from CWV ranking signal: 8-15 percent uplift on competitive queries over 60-90 days. - Implementation discipline. Don’t ship all 10 fixes in one deploy. Batch by image type: deploy hero-image fixes in week 1, PDP image fixes in week 2, collection + logo + icon fixes in week 3. Each batch has a measurable impact on page weight and CWV; staged deploys allow attribution.
- Read top 5 entries. Image URL + current bytes + target bytes is the actionable detail.
- Verify in DevTools. Network tab confirms the actual transfer size; some images may be served pre-compressed by the CDN at smaller sizes than Lighthouse measures.
- Identify the upload-time vs serve-time fix. If source images are too large, fix at upload (cap source at 2000px wide). If source is fine but CDN config is suboptimal, fix at CDN.
- Ship in batches. Group fixes by image type or template; ship and measure each batch.
- Re-audit after each ship. Confirm savings; reassess remaining ranking.
Sibling cards merchants should reference together
Reconciling against the vendor’s own dashboard
Where to look in PageSpeed Insights / DevTools:- PageSpeed Insights, “Opportunities” section shows “Properly size images”, “Serve images in next-gen formats”, “Defer offscreen images” with per-image detail.
- Chrome DevTools → Network tab, filter by Image; sort by transfer size; identify oversized resources directly.
- Chrome DevTools → Coverage tab, for embedded image data URIs in CSS/JS bundles.
- WebPageTest, provides a per-image breakdown with format, dimensions, and savings recommendations.
Cross-connector reconciliation:
Quick rule for support tickets: if a merchant says “I converted my hero image to WebP but the opportunity is still showing”, the most common cause is CDN serving the old PNG version due to cache TTL. Purge the CDN cache for the affected URLs and re-audit; the opportunity should drop within minutes.
Known limitations / merchant FAQs
My designer insists on PNG for product images. Can I keep PNG? Sometimes. PNG is required for images with transparency (logos, icons, product cut-outs) and best for images with sharp edges or text. For photographic product images on plain backgrounds, JPEG or WebP is significantly smaller with no visible quality difference. The pragmatic rule: PNG only when transparency is required; everything else as WebP (with JPEG fallback for very old browsers). Brands that use PNG by default for everything ship 2-4x larger images than necessary. Will WebP look worse than my JPEGs? At equivalent file sizes, no, WebP at quality 75 typically matches JPEG at quality 90 visually. The savings come from format efficiency, not quality reduction. Side-by-side comparisons show no perceptible difference for most ecommerce imagery. The exception: images with high-contrast text or fine line detail can show very subtle differences; for those use AVIF or PNG. Can I just use the largest image on every page? Technically yes; commercially no. Serving a 2000px image on a 412px mobile viewport wastes 95+ percent of the bytes. Mobile users on slow networks experience the cost most: a 2MB hero image takes 12+ seconds on slow 4G; a 200KB responsive variant takes under 2 seconds. The conversion-rate impact of the difference is large. My BC theme handles image sizing automatically. Do I need to do anything? Partially. BC’s image CDN serves resized variants automatically based on thesrcset declaration in the theme. The merchant’s responsibility: ensure source images upload at reasonable resolution (cap at 2000px wide) and ensure theme templates use srcset properly. The Stencil theme defaults are usually OK; custom modifications can break the responsive serving.
Should I optimise images at upload time or via CDN?
Both. Upload-time discipline prevents 10MB raw photos from entering the system. CDN-time optimisation handles per-request format negotiation and resizing. The combination is more robust than either alone: source discipline keeps the upper bound reasonable; CDN handles per-device variants automatically.
My logo is a PNG with transparency. Is that OK?
Acceptable but not optimal. SVG is the right format for logos: scales infinitely, looks sharp at all densities, often smaller than even compressed PNG. If the logo is genuinely raster (photo-realistic, complex gradients), PNG with transparency is fine; for vector-friendly logos (most brand marks), convert to SVG.
Lighthouse says my images are oversized but they look fine. Are they really a problem?
Yes, even though they look fine. The issue isn’t visual quality; it’s bytes downloaded. Mobile users on slow networks experience the byte cost as load delay; you don’t see this on your own fast connection. The Lighthouse mobile profile (slow 4G, mid-tier hardware) emulates the average mobile user; the data tells the truth even when subjective experience disagrees.
Can Vortex IQ optimise images for me?
Read-only by design. Vortex IQ identifies which images need work and ranks them by impact; the merchant’s developer or asset manager executes the optimisation. The Vortex Mind Pre-Launch Readiness report can create Kanban tasks per image with specific recommendations.
Should I move to AVIF instead of WebP?
Eventually yes. AVIF saves 20-30 percent more bytes than WebP at equivalent quality. Browser support is now strong enough (~89 percent global). The pragmatic approach: serve AVIF first, WebP as the next-priority fallback, JPEG as the universal fallback. The <picture> element handles this automatically.