Image Optimization for Ecommerce: Formats, Resizing, and Delivery

Product imagery is part of the selling experience, but it is often also the largest payload on a category or product page. A store can have fast HTML and still feel slow because it downloads a 3,000-pixel photograph into a 320-pixel mobile slot, delays its largest contentful paint, or shifts the layout when an image finally arrives.

The practical solution is not "compress everything." It is a delivery system: choose the right source and crop, generate a bounded set of dimensions and formats, expose the browser's choices, reserve layout space, load critical images early, and cache stable variants at the edge. Google's web.dev image performance guidance and image SEO documentation provide useful standards-based references.

1. Inventory images by job

Start with representative pages: home, category, search, product detail, cart, and promotional landing pages. Record each image's rendered width, aspect ratio, file size, format, loading priority, and whether it is above the fold. Separate:

• Product photos that need consistent crops and visual fidelity.
• Hero banners that may need art direction for mobile.
• Thumbnails and swatches that can use smaller dimensions.
• Logos and interface graphics that may be better as SVG.
• Decorative images that should not compete with product content.

Use the rendered slot, not the source file, as the starting point. A 1,200 CSS-pixel image may need a 2x candidate for a high-density display, but it does not automatically need the original 4,000-pixel upload. Keep the master original for editing; optimize the delivery derivative.

2. Choose formats by content and support

For photographs, test AVIF and WebP against a JPEG fallback. AVIF can be smaller at comparable visual quality, while WebP has broad modern-browser support. JPEG remains a practical fallback for older clients and systems. For transparency, test WebP or AVIF against PNG; for line art, text, and logos, SVG or lossless formats may preserve edges better.

There is no universal quality number. Compare images at their actual display size, including product labels, fine fabric texture, skin tones, and color accuracy. A smaller file with visible ringing or blur is not an optimization for a retail brand.

If the server selects a representation from the request's Accept header, make the cache aware of that variation through Vary: Accept or an equivalent provider-supported variant policy. Otherwise, one browser can receive a format it does not support. The web.dev format guidance explains the trade-offs and fallback pattern.

3. Generate responsive dimensions

Use srcset with width descriptors and sizes that describe the layout. A simplified pattern looks like this:

<img
  src="/shoe-800.webp"
  srcset="/shoe-400.webp 400w, /shoe-800.webp 800w, /shoe-1200.webp 1200w"
  sizes="(min-width: 1024px) 33vw, 50vw"
  width="800"
  height="1000"
  alt="Blue running shoe, side view"
>

The browser can choose a candidate based on the viewport and device pixel ratio. sizes matters: if it says 100vw for an image displayed in a narrow card, the browser may download a needlessly large file. If it understates the slot, the result may be soft on high-density screens.

Keep the candidate ladder bounded. A variant for every possible width increases storage, transformation work, cache entries, and cold misses. Choose dimensions around real layout breakpoints and measure whether another size meaningfully reduces bytes. For art-directed banners, use picture with a mobile crop rather than forcing one desktop composition into every aspect ratio.

4. Protect LCP and layout stability

Identify the LCP element in a lab trace and confirm it in field data. For the LCP image, use a normal discoverable <img> or <picture>, avoid loading="lazy", and consider fetchpriority="high" when the browser needs an explicit signal. Do not preload every image: competing preloads can make the critical request slower.

Reserve the image's aspect ratio with width and height attributes or CSS aspect-ratio. This prevents content below the image from moving as the response arrives and helps control Cumulative Layout Shift. Use a placeholder with the same dimensions and crop behavior. A blurred preview can be useful, but it should not delay the real image or require heavy client-side work.

Below-the-fold gallery images, recommendation cards, and footer media can use lazy loading. Test the distance threshold on slow connections so users do not scroll into an empty gallery, but do not load the entire catalogue before it is needed.

5. Deliver and cache variants efficiently

An image CDN or edge transformation layer can select a format, width, quality, crop, and focus point from a controlled URL scheme. Optimi's Adaptive Image page describes this delivery pattern. Whether transformations happen at build time, on the origin, or at the edge, the URL must identify the output deterministically so it can be cached safely.

Use long lifetimes for immutable variant URLs. When a source image changes, change its version or purge its associated tag and all required derivatives. Do not rely on purging one original URL to refresh every transformed URL unless the provider explicitly guarantees that relationship. Review cache keys for width, format, quality, crop, locale, and device hints.

Avoid an unbounded quality parameter supplied directly by users. Normalize values into a small approved set. Limit maximum dimensions and transformation operations, and reject malformed or remote fetch URLs to prevent resource abuse. These are delivery controls as much as performance controls.

6. Verify across real page types

Use a matrix that includes slow mobile, high-density mobile, desktop, different browsers, and representative geographic regions. For each page type, check:

• Requested format and intrinsic dimensions.
• Transfer size and decoded size.
• Content-Type, Cache-Control, Age, and cache-status headers.
• Correct crop, focus, color, and fallback behavior.
• LCP, CLS, and visual quality at the actual slot size.
• Repeat-request cache hits and origin transformation volume.

PageSpeed Insights uses real-user data over a recent collection period and reports the 75th percentile when sufficient data exists. Combine it with browser DevTools, a trace, and an image inventory. A lab score can improve while a high-value mobile category page still serves oversized images.

Rollback safely

Keep the previous image URL and transformation policy available while the new pipeline is tested. If AVIF decoding, color, crop, or transformation latency is wrong, switch the format preference or URL template back to the known-good WebP or JPEG path. If a bad source was published, correct it at the origin, invalidate its tags or URLs, and verify several variants before reopening the rollout.

Do not delete old assets immediately after changing HTML. Cached pages, search results, emails, and browsers may still request them. Retaining a previous immutable asset is usually cheaper and safer than forcing every client through a synchronized purge.

Common mistakes

• Serving the original upload to every viewport.
• Treating AVIF as a replacement with no fallback testing.
• Omitting sizes, or providing a value that does not match the layout.
• Lazy-loading the LCP image.
• Omitting intrinsic dimensions and causing layout shifts.
• Creating hundreds of near-duplicate variants that never become warm.
• Ignoring Vary: Accept when format negotiation happens at the origin.
• Purging the source URL while transformed derivatives remain cached.
• Optimizing bytes without checking product detail, color, crop, and zoom quality.

For cache policy, read the static vs dynamic content guide. For delivery architecture, see Optimi's managed CDN guide, and for ecommerce priorities review the ecommerce solution. The cache purging workflow covers versioning and derivative invalidation.

There are only two hard things in Computer Science: cache invalidation and naming things.