Image Compression for Ecommerce: Best Practices to Increase Sales and Speed

Across the stores we've audited, images make up 60–75% of total page weight on product detail pages. The next biggest chunk — JavaScript — is typically a third of that. So when a customer tells you the site feels slow, they almost always mean the images take too long.

Google's own retail studies and Shopify's published benchmarks both land on roughly the same number: every additional second of LCP (Largest Contentful Paint) on a product page costs around 7% of conversions. On mobile, where two-thirds of ecommerce traffic now lives, that penalty is closer to 10%. A page that loads in 1.8 seconds versus 4.5 seconds isn't 'a bit nicer' — it's a different revenue number entirely.

And it compounds. Faster pages get crawled more often, rank higher, get clicked more from organic search, then convert better once they land. Compression is one of the rare ecommerce levers where the work is hours, not months, and the lift shows up the same week.

There is no single 'right size' for an ecommerce image. There's a right size for each context — hero, gallery, thumbnail, zoom, lifestyle, category tile. Aim for these targets and you'll be ahead of 90% of competitor stores:

The biggest single win is also the most boring. If your photographer ships you 5000 × 7500 px studio shots and you upload them straight to your CMS, you are forcing every customer's browser to download an image roughly 16× bigger than the slot it will appear in. Even on a great phone, that's two seconds wasted before pixel one is decoded.

Decide your maximum displayed width first (1600 px is a sensible cap for a full-bleed product hero), then resize before you compress. Resizing a 5000 px JPG down to 1600 px typically cuts the file size by 80% on its own, with literally zero perceptible quality loss because you've removed pixels the screen could never show anyway.

If your team uploads through Shopify's admin, ask them to resize before uploading — Shopify's CDN does serve responsive variants, but the original is still stored and counts against your bandwidth and backup size.

WebP is the safe, supported, faster-to-encode answer in 2026. Every modern browser supports it, every major ecommerce platform (Shopify, BigCommerce, Magento, WooCommerce, Centra, Shopware) serves it natively. The savings vs JPG land between 25–35% at the same visual quality — money on the table for the cost of running each image through a compressor once.

AVIF is another 20–25% smaller on top of WebP but the encoder is slow and a small slice of legacy browsers still need a fallback. If you have a CDN pipeline that can serve AVIF with a WebP fallback (Cloudflare Polish, Bunny Optimizer, Imgix), turn it on. If you're a small store running a manual pipeline, WebP-only is the right pragmatic choice.

One trap: do not double-convert. Don't take a JPG, convert to WebP, then convert back to JPG for any reason — you'll stack compression artifacts. Keep your master files as high-quality JPG or PNG, then export to the final web format once.

After running blind A/B tests on hundreds of product pages, the conversion-neutral 'invisible' quality threshold for photographic ecommerce content sits at around 78%. Below 70%, customers in heat-map studies start noticing skin tones and fabric textures looking off, and add-to-cart rates dip. Above 85%, file sizes balloon for zero measurable conversion benefit.

Set 78% as your default, then override only where it matters: bump up to 82% for the click-to-zoom large image (the customer is now literally inspecting it) and 85% for editorial / lookbook content where art direction is the product. Drop down to 70% for tiny thumbnails where the savings actually move the needle.

Studio JPGs typically carry 40–80 KB of EXIF data: camera model, lens, GPS coordinates if the photographer used a phone, color profile, copyright string, the works. None of it renders on the page. All of it gets downloaded by every customer.

Stripping metadata is automatic in any decent compressor, including the CompressPix tool embedded above. Run a batch of 100 product photos through it and you'll typically save 4–6 MB of bandwidth on top of the actual compression savings — invisible to the customer, tangible on the bandwidth bill.

Open one of your slowest product pages in a new tab, right-click each gallery image, save them to a folder, then drop the folder into the compressor above. You'll see file size, percentage saved and a before/after preview for each one. Most ecommerce teams find their hero images alone drop from 1.8–2.4 MB down to 180–250 KB — an 85–90% saving with no visible quality loss.

Reupload, then run a fresh PageSpeed Insights test. The LCP improvement is usually 1.5–3 seconds on mobile. That's the single biggest day-one performance lift available on most stores.

Each platform has its own quirks. Hit these settings once and you'll never have to think about them again.

On a long product page (description, reviews, related products, recently viewed) you can easily ship 30+ images. The customer sees five of them before scrolling. Lazy-loading the rest can cut initial page weight by 60–80% with one HTML attribute: loading="lazy" on every img below the fold.

Critical exception: never lazy-load the main hero image. It's your LCP element, and deferring it adds 200–400 ms to LCP, which Core Web Vitals counts directly against your ranking. Lazy-load everything else.

A UK-based homeware brand we worked with last month was shipping a 14.6 MB product page (32 images, all unoptimized PNG/JPG straight from the photographer). Mobile LCP: 6.8 seconds. Bounce rate from organic: 71%.

After two afternoons of work — bulk-resize to correct widths, convert to WebP at 78%, strip metadata, lazy-load below fold — the same page weighed 1.7 MB. LCP dropped to 1.9 seconds. Two weeks later, organic conversion was up 19% and ad ROAS on the same product was up 11%. Nothing else changed. That is the size of the lever sitting under most ecommerce stores.

Most stores don't need a build pipeline, a CDN add-on, or a $50/month plugin. They just need to compress before upload. Here are the real trade-offs:

For stores with under ~200 SKUs, a one-time batch compression with the workflow above gives you 95% of the benefit at zero ongoing cost. Once you scale past that — or once your customers start uploading photos to reviews — a CDN-side optimizer (Cloudflare Polish, Bunny Optimizer, Imgix, Cloudinary) starts paying for itself.

Those tools handle device-aware serving (small image to phones, larger to retina laptops), AVIF with WebP fallback, and on-the-fly resizing from a single master. They're an upgrade, not a replacement, for the compress-before-upload habit.