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.
| What it counts | List of images flagged by Lighthouse audits: (a) Properly size images: served larger than displayed size (e.g. 1920px image displayed in a 412px mobile viewport). (b) Serve images in next-gen formats: PNG/JPEG candidates for WebP or AVIF conversion. (c) Efficiently encode images: JPEG quality above 85 with low visual benefit. (d) Defer offscreen images: images below the fold loading at page-load instead of lazy-loading. Each entry: URL, current size, target size, byte savings. |
| Sample type | Lab data from Lighthouse audit. Reflects the page’s served images at audit time. |
| Device profile | Mobile by default. Mobile shows the most opportunities because mobile viewports (typically 375-414px wide) display far smaller than desktop, so over-sized images are most evident there. |
| Common patterns on BC stores | (1) Hero carousel images uploaded as PNG at 1920×1080, displayed at 412×232 on mobile; bytes-saved 60-80 percent via WebP + responsive variants. (2) Product detail page hero images at 1500×1500 JPEG quality 95, displayed at 412×412; bytes-saved 50-70 percent via quality reduction to 80-85 + WebP. (3) Collection grid images at 600×600 JPEG, displayed at 200×200; bytes-saved 40-60 percent via responsive variants. (4) Logo images as PNG with transparency, often unnecessarily large (32KB when 8KB SVG would work). |
| WebP and AVIF support | WebP is supported by all modern browsers (97 percent global; 99 percent in UK/US) since 2020. AVIF is supported by Chrome and Safari (~89 percent global) but not all email clients or older Android browsers. Recommended approach: serve AVIF for browsers that support it (<picture> with <source type="image/avif">), WebP as the next-priority fallback, JPEG as the universal fallback. |
| Quality settings | JPEG quality 80-85 is the sweet spot for ecommerce: 30-50 percent smaller than quality 95 with no visible difference. Quality 70-75 for images where size matters more than fidelity (collection thumbnails). Quality 90+ only when colour-critical (luxury brands, high-detail product photography). |
| Responsive variants | Best practice: serve 3-5 width variants per image (e.g. 400px, 800px, 1200px, 1600px, 2000px) and use <img srcset> + sizes attribute so browsers pick the right variant for the user’s viewport + device pixel ratio. Cuts mobile bytes by 50-70 percent vs serving the full-resolution original. |
| CDN-driven optimisation | Cloudinary, imgix, BC’s image CDN, Shopify’s image CDN handle format negotiation + responsive resizing automatically when configured. The merchant’s responsibility: ensure source images are uploaded at reasonable resolution (cap at 2000px wide), set sensible defaults (e.g. q_auto:eco on Cloudinary for ~85 quality auto-format). The CDN does the per-request work. |
| Currency | n/a, this is a list of byte-savings opportunities. |
| Time window | T (current state from latest audit). |
| Alert trigger | top opportunity > 200KB savings (any single image worth over 200KB of savings 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 audit, mobile, Wednesday 15 May 26.| Rank | Image URL | Current | Target | Savings | Issue |
|---|---|---|---|---|---|
| 1 | /content/hero-spring-collection.png | 2,840KB | 280KB | 2,560KB | PNG at 1920×1080 displayed at 412×232; convert to WebP, serve responsive variants |
| 2 | /content/hero-bestsellers.png | 2,720KB | 270KB | 2,450KB | Same pattern; same fix |
| 3 | /content/hero-summer-2026.png | 2,580KB | 260KB | 2,320KB | Same |
| 4 | /content/hero-new-arrivals.png | 2,100KB | 240KB | 1,860KB | Same |
| 5 | /products/product-1234-detail-1.jpeg | 480KB | 120KB | 360KB | JPEG quality 95 at 1500×1500; reduce to quality 82 + WebP |
| 6 | /products/product-5678-detail-1.jpeg | 460KB | 115KB | 345KB | Same pattern |
| 7 | /collection/category-banner-spring.png | 380KB | 60KB | 320KB | PNG with transparency at 1200×400; WebP + 800px variant for mobile |
| 8 | /products/product-1234-thumbnail.jpeg | 180KB | 45KB | 135KB | Quality 90 at 600×600 displayed at 200×200; reduce to quality 80 + responsive variants |
| 9 | /logo/site-logo-large.png | 32KB | 4KB | 28KB | Convert to SVG (vector logo) |
| 10 | /icons/payment-method-stripe.png | 18KB | 3KB | 15KB | Convert to SVG (vector icon) |
| Top-10 savings | 9,790KB | 1,397KB | 8,393KB (87% reduction) | ||
| Total page | (4,440KB) | (1,800KB) | (2,640KB savings) | Headline page weight drops 60% |
-
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.
| Time horizon | Action |
|---|---|
| First 1 hour | Identify top 5 entries; understand the fix per entry. |
| First 24 hours | Re-export hero images as WebP responsive variants; deploy. |
| First 7 days | Measure mobile LCP delta. Move to PDP images. |
| First 14 days | Measure CWV pass rate delta (28-day window starting to absorb). |
| First 28 days | Full reflection of fixes in field metrics. |
Sibling cards merchants should reference together
| Card | Why merchants reach for it |
|---|---|
psi_top_opportunities_bytes | Composite byte-savings ranking across all opportunity types. |
psi_top_opportunities_ms | Same opportunities ranked by millisecond savings. Image fixes typically rank #1. |
psi_total_weight | Total page weight; image fixes drive most reduction. |
psi_weight_by_type | Per-type breakdown; images typically 40-60 percent of weight. |
crux_lcp_p75 | LCP correlates with image weight and serving format. |
psi_perf_score_summary | Composite score; image fixes deliver the largest single uplift on most ecommerce sites. |
psi_render_blocking | Render-blocking resources; image preload matters for hero LCP. |
psi_caching_opportunities | Caching reduces repeat-visit image bytes. |
psi_third_party_cost | Third-party scripts often inject their own images; cost compounds. |
GSC gsc_mobile_usable_pages | Mobile usability; image-heavy pages often fail mobile-friendliness checks. |
| BC catalog quality audit | BC-specific image-management practices; product image upload discipline. |
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.
| Reason | Direction | What to do |
|---|---|---|
CDN format negotiation. Vortex IQ’s audit may receive WebP from the CDN if it sends Accept: image/webp; PSI’s audit always identifies as Chrome and gets the same. | Usually match | Confirm Accept header behaviour in DevTools. |
| Cache state. Vortex IQ runs cold-cache; DevTools runs may have warm cache. | Vortex IQ higher byte counts | Use disabled-cache for direct comparison. |
| Audit timing. Different audit times capture different image variants (rotating campaign banners, A/B test variants). | Either direction | Use 7-day rolling for trend reads. |
| Lighthouse threshold. Lighthouse drops opportunities under ~10KB savings; very small per-image savings don’t appear even when they exist. | Vortex IQ matches Lighthouse | Add manual checks for small-image patterns if needed. |
| Comparison | Expected relationship | When divergence is legitimate |
|---|---|---|
psi_image_optimisation ↔ crux_lcp_p75 (post-fix) | Image-savings byte reductions translate to LCP improvement | Real-world LCP improvement scales with image weight reduction at roughly 1ms per KB on mobile slow-4G. A 2,000KB image fix typically saves 1,500-2,500ms LCP. |
psi_image_optimisation ↔ psi_total_weight | Image fixes drive most weight reduction | The byte savings here are a subset of total page weight reduction. |
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.