> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # Image Optimisation, Website Performance (PageSpeed + CrUX) > Image Optimisation for Website Performance (PageSpeed + CrUX) stores. Tracked live in Vortex IQ Nerve Centre. How to read it, why it matters, and how to ac... **Metrics type:** [Supporting Metrics](/nerve-centre/overview#metrics-types-explained) • **Category:** [Website Performance](/nerve-centre/connectors#connectors-by-type) ## 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 (`` with ``), 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 `` + `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% | What the ranked list is telling us: 1. **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 `` declarations in the theme's hero-carousel template. Time investment: 4-6 hours for a developer familiar with BC theme structure. 2. **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. 3. **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. 4. **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. 5. **Cumulative impact**: top-10 image fixes save 8,393KB. Combined with the JS deferral and font optimisation work from the [`psi_top_opportunities_ms`](/nerve-centre/kpi-cards/website-performance/top-opportunities) ranking, 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. 6. **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. The diagnostic flow: 1. **Read top 5 entries.** Image URL + current bytes + target bytes is the actionable detail. 2. **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. 3. **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. 4. **Ship in batches.** Group fixes by image type or template; ship and measure each batch. 5. **Re-audit after each ship.** Confirm savings; reassess remaining ranking. The rapid-response playbook: | 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`](/nerve-centre/kpi-cards/website-performance/top-opportunities) | Composite byte-savings ranking across all opportunity types. | | [`psi_top_opportunities_ms`](/nerve-centre/kpi-cards/website-performance/top-opportunities) | Same opportunities ranked by millisecond savings. Image fixes typically rank #1. | | [`psi_total_weight`](/nerve-centre/kpi-cards/website-performance/total-page-weight) | Total page weight; image fixes drive most reduction. | | [`psi_weight_by_type`](/nerve-centre/kpi-cards/website-performance/weight-by-resource-type) | Per-type breakdown; images typically 40-60 percent of weight. | | [`crux_lcp_p75`](/nerve-centre/kpi-cards/website-performance/page-load-speed) | LCP correlates with image weight and serving format. | | [`psi_perf_score_summary`](/nerve-centre/kpi-cards/website-performance/performance-score-summary) | Composite score; image fixes deliver the largest single uplift on most ecommerce sites. | | [`psi_render_blocking`](/nerve-centre/kpi-cards/website-performance/render-blocking-resources) | Render-blocking resources; image preload matters for hero LCP. | | [`psi_caching_opportunities`](/nerve-centre/kpi-cards/website-performance/caching-opportunities) | Caching reduces repeat-visit image bytes. | | [`psi_third_party_cost`](/nerve-centre/kpi-cards/website-performance/third-party-cost) | Third-party scripts often inject their own images; cost compounds. | | [GSC `gsc_mobile_usable_pages`](/nerve-centre/google_search_console/gsc_mobile_usable_pages) | Mobile usability; image-heavy pages often fail mobile-friendliness checks. | | [BC catalog quality audit](/nerve-centre/kpi-cards/bigcommerce) | 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](https://pagespeed.web.dev)**, "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. **Why the Vortex IQ image rankings may legitimately differ from PSI:** | 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. | **Cross-connector reconciliation:** | Comparison | Expected relationship | When divergence is legitimate | | ------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `psi_image_optimisation` ↔ [`crux_lcp_p75`](/nerve-centre/kpi-cards/website-performance/page-load-speed) (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`](/nerve-centre/kpi-cards/website-performance/total-page-weight) | Image fixes drive most weight reduction | The byte savings here are a subset of total page weight reduction. | **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 the `srcset` 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 `` element handles this automatically. *** ### Tracked live in Vortex IQ Nerve Centre *Image Optimisation* is one of hundreds of KPI pulses Vortex IQ tracks across Website Performance (PageSpeed + CrUX) and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. [Start for free](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.