What image compression settings actually move conversion rates

The short answer: Serve WebP at quality 80 for most product images, use a <picture> element to fall back to JPEG, and keep your primary product shot above SSIM 0.94. Those three changes reduce page weight by 30-50% on most stores without any visible quality loss.

Most conversations about image compression start and end with file size. That framing skips the revenue question: which settings cut weight without triggering visual degradation that kills purchase confidence.

Load time and revenue

Pages that load in one second convert at roughly three times the rate of pages that load in five seconds. Google's research at web.dev/performance puts this relationship clearly. The steepest drop in conversion probability happens between 1 and 3 seconds. On mobile, where most e-commerce traffic now lands, the gap compounds.

LCP (Largest Contentful Paint) captures this most directly. Pages with LCP under 2.5 seconds are in Google's "good" range. Slower than that and you're losing both conversions and organic ranking, since Core Web Vitals feed into search signals.

Images account for 60-70% of total page weight on most sites I've audited.

Format gains by the numbers

The format you serve matters more than the quality slider. AVIF and WebP both offer meaningful compression gains over JPEG. WebP typically runs 25-34% smaller than an equivalent JPEG, and AVIF pushes further, 45-55% smaller on noisy, high-frequency content like fabric texture, skin detail, or food photography with fine grain. Browser support for both formats is above 94% as of 2025 (current data at caniuse.com).

Format	Typical size vs. JPEG baseline	Browser support (2025)
JPEG	baseline	~98%
WebP	25-34% smaller	~95%
AVIF	45-55% smaller	~94%

The practical serving approach is a format ladder: AVIF to browsers that support it, WebP as the fallback, JPEG for everything else. Every major image CDN handles this automatically via the Accept header. If you manage assets in a DAM like Pixel Wand, format conversion on upload lets you store once and deliver the right format per request without touching your frontend.

<picture>
  <source srcset="product.avif" type="image/avif">
  <source srcset="product.webp" type="image/webp">
  <img src="product.jpg" alt="Product name" width="800" height="600">
</picture>

AVIF encoding runs 5-10x slower than WebP. For large libraries, batch encoding at upload time is the only sane approach. Real-time AVIF conversion on request adds latency that defeats the point.

Hot take: For stores under a few thousand SKUs without a proper asset pipeline, AVIF is often more complexity than it's worth right now. WebP at quality 80 gets you 80% of the gains with a fraction of the encoding overhead. I've seen brands spend weeks on AVIF tooling that moved their LCP by 80ms. WebP conversion done in an afternoon moved it by 400ms. Use WebP as your starting point and revisit AVIF once your pipeline is solid.

What quality settings should you actually use?

For JPEG, the range that matters is 75-85. Quality 80 typically delivers 40-60% smaller files than quality 95 with no visible difference at standard viewing distances. Below 75, blocking artifacts appear around high-contrast edges, exactly the kind of degradation that makes product images look cheap and drives the bounce rates you're trying to fix.

The encoder matters as much as the quality number. MozJPEG at quality 80 produces output that's perceptually comparable to a standard JPEG encoder at quality 90, with a meaningfully smaller file. If your pipeline isn't using MozJPEG or a similar modern encoder, the quality setting you think you're using isn't telling the full story.

For WebP, quality 80 is the practical sweet spot. Above 85, file size returns diminish while encoding time increases. Below 75, the same artifact problems as JPEG appear, though WebP handles them slightly better at equivalent quality numbers.

AVIF quality scales differently. A setting of 60-70 in libavif or sharp tends to produce output equivalent to JPEG at 80-85. The numbers aren't comparable across formats. Don't apply your JPEG intuitions directly.

The one place to push quality higher: hero images and primary product shots on high-DPI displays. If you're serving a 1200px wide hero image that anchors your LCP element, quality 85-90 is worth the extra bytes. The perceptual stakes are higher, and it's the first thing the user sees.

How do you measure compression quality without guessing?

If you want to set quality levels by data rather than by eye, SSIM (Structural Similarity Index) gives you a perceptual quality score rather than a raw pixel-difference score. An SSIM of 1.0 is lossless. In my testing, most web images are acceptable above 0.92 and genuinely good above 0.97.

The workflow: encode at several quality levels, measure SSIM against the original, pick the lowest quality level that stays above your threshold. For product images, 0.94 is a reasonable floor in my testing. For decorative backgrounds or blog headers, 0.90 is fine.

# Using ffmpeg to measure SSIM between original and compressed
ffmpeg -i original.jpg -i compressed.webp -filter_complex ssim -f null -

Takes about three minutes to set up, and it makes quality decisions reproducible across a pipeline that processes thousands of assets.

Compression choices that hurt conversions

Compression artifacts on the primary product image are the one compression choice that costs money directly.

In my experience working with fashion and home goods stores, aggressive compression on hero and primary product shots is the single most common self-inflicted conversion problem I see. The image makes the product look low-resolution or cheap, and the customer bounces before reading a word of copy.

The artifacts to watch for: blocking around sharp edges (JPEG at low quality), color banding on smooth gradients (AVIF at aggressive settings), and chroma blur that destroys fine detail like stitching, texture, or surface finish. Each of those problems correlates directly with lower add-to-cart rates.

Background images, blog headers, and decorative illustrations are different. These can take more aggressive compression because the user isn't examining them for product detail. A clothing product at quality 65 WebP will show artifacts; decorative headers can go lower.

Why image sizing matters as much as compression

Format and quality only matter if the image dimensions match the container. Serving a 2400px wide image into a 400px container wastes bandwidth regardless of compression quality. Responsive images with srcset fix this:

<img
  srcset="product-400.webp 400w, product-800.webp 800w, product-1200.webp 1200w"
  sizes="(max-width: 600px) 400px, (max-width: 1000px) 800px, 1200px"
  src="product-800.webp"
  alt="Product name"
>

Generate size derivatives at upload time, not on request. The work happens once, and every subsequent load is fast.

FAQ

Does image compression directly affect Google rankings? Indirectly, yes. Google uses Core Web Vitals, including LCP, as a ranking signal. Images are the most common LCP element on product pages. Compressing them well is one of the fastest ways to improve LCP, which feeds into ranking. I've seen stores recover meaningful organic visibility after fixing image weight, though it's hard to isolate from other changes.

Should I use lossless compression for product images? Generally no. Lossless WebP files run 2-3x larger than lossy WebP at quality 80. The visual difference is imperceptible at normal screen resolutions. Lossless makes sense for assets you'll re-edit, not for delivery to customers.

What quality setting should I start with? Start at 80 in whatever format you're using. Compare the output against the original at 100% zoom. If you can't spot the difference, you're done. If you can, go to 82 and check again. Most product images settle at 78-83.

How do I handle images that look fine on desktop but bad on mobile? The compression settings are usually not the problem. You're almost certainly serving the same large image to mobile. Add srcset with a 400-600px breakpoint for mobile, and make sure that mobile variant is also encoded at the right quality for its dimensions. A 400px wide image at quality 80 WebP will be around 20-35KB for a typical product shot. If it's still looking soft or blocky at that size, check whether your image pipeline is downscaling from a very large source without re-encoding: some resizing tools carry over JPEG artifacts rather than recompressing cleanly. Run the resized output through MozJPEG or sharp explicitly and the problem usually goes away.

What to do right now

Pick your three highest-traffic product or hero images. Run them through format conversion to WebP at quality 80 using sharp or squoosh. Compare file sizes and load them in a browser at full resolution. If you can't see a difference and the files are 30-50% smaller, apply that setting across your library. If there are artifacts, go to 82 and repeat.