Image Optimization for Web Performance: A Complete Guide to Compression and Resizing

Run a PageSpeed Insights audit on almost any website and the top recommendation is usually images. HTTP Archive data consistently shows images accounting for over half of the median page's transfer weight — more than JavaScript, CSS, fonts, and HTML combined. Content-heavy sites regularly ship 3-5MB of image data, and the 3-second load time threshold is where bounce rates start climbing sharply.

Google embedded page performance directly into rankings through Core Web Vitals. Largest Contentful Paint (LCP) — which is almost always an image — is the vital most sites fail. I've seen sites cut total page weight by 70% just from image optimization, with zero visible quality change. It's the highest-leverage performance work for the majority of websites.

Lossless vs lossy: what's actually being thrown away

Lossless compression (PNG) encodes pixel data more efficiently without discarding anything — the decompressed image is bit-for-bit identical to the original. Lossy compression (JPEG, WebP) discards information the human visual system is unlikely to notice, achieving dramatically smaller file sizes at the cost of imperceptible quality reduction. For photographs on the web, lossy compression is almost always the right choice.

The mechanism behind lossy compression is that your visual system is far more sensitive to brightness changes (luminance) than color changes (chrominance). JPEG converts pixels to YCbCr color space and subsamples the chroma channels — it stores color at half the resolution of brightness. WebP's lossy mode goes further with predictive coding: it analyzes neighboring pixels to estimate values and encodes only the differences.

Format choice matters more than compression settings

Format choice has a larger impact on file size than any quality setting. Switching a photograph from PNG to WebP can cut size by 70% at the same perceived quality. Each format has a specific use case it's optimized for:

JPEG: photographs and smooth gradients. Quality 80-85 achieves excellent compression with minimal visible artifacts. Doesn't support transparency.
PNG: screenshots, diagrams, logos, anything needing transparency. Lossless, but noticeably larger than lossy formats for photographs.
WebP: supports both lossy and lossless modes, transparency, and animation. Lossy WebP is 25-35% smaller than equivalent-quality JPEG. Supported in Chrome 32+, Firefox 65+, Safari 14+.
AVIF: 20-30% better compression than WebP, based on the AV1 codec. Slower to encode. Best for sites that can serve format-specific responses via the Accept header.
SVG: vector format for icons and illustrations. Often under 5KB for simple graphics and scales to any resolution.

The Quality Setting Sweet Spot

The quality parameter (0-100) is nonlinear. Dropping from quality 100 to 85 typically cuts file size by 60-70% with changes invisible to the naked eye. Going from 85 to 70 saves another 20% but introduces visible artifacts on close inspection. Below 50, you'll notice it even at a normal viewing distance.

The practical sweet spot is quality 75-85 for JPEG and 75-80 for WebP. A 4000x3000 photograph that weighs 8MB as an uncompressed PNG compresses to roughly 400KB as JPEG-80, or 300KB as WebP-80. That's a 95-97% size reduction with no perceptible quality loss at typical web display sizes.

Never re-compress an already-compressed JPEG. Re-encoding adds a second generation of lossy artifacts with no meaningful size reduction — you're degrading quality for nothing. Always compress from the highest-quality source: the original camera file or your design tool's raw export.

Resizing: The Most Overlooked Optimization

The most impactful optimization is often the simplest: don't serve images larger than they need to be. A 4000x3000 photograph displayed at 800x600 contains 20 million pixels, but the browser only uses 480,000 of them. The other 97.5% get downloaded, decoded, and discarded.

The picture element and srcset attribute let you serve different image sizes to different viewport widths. Generate 3-4 sizes (400w, 800w, 1200w, 1600w) and let the browser pick the right one. For Retina/high-DPI displays, serve 2x the CSS display size — an 800px-wide container gets a 1600px image on a 2x display. Next.js, Vite, and most build pipelines can automate this.

html

<!-- Responsive image with srcset -->
<img
  src="photo-800w.webp"
  srcset="photo-400w.webp 400w,
          photo-800w.webp 800w,
          photo-1200w.webp 1200w,
          photo-1600w.webp 1600w"
  sizes="(max-width: 600px) 100vw,
         (max-width: 1200px) 50vw,
         800px"
  alt="Description of the photo"
  width="800"
  height="600"
  loading="lazy"
/>

Lazy Loading and Layout Shift Prevention

Native lazy loading (loading="lazy") defers off-screen image downloads until the user scrolls near them. It's one line of HTML and it can dramatically cut initial page load on long pages. The catch: don't lazy-load your LCP image. The hero image or primary above-the-fold content should load eagerly (omit the attribute entirely) — lazy-loading it will inflate your LCP score.

To prevent Cumulative Layout Shift (CLS) — the jarring visual jump when an image loads and pushes content down — always specify width and height attributes on img tags. Modern browsers use these to calculate the aspect ratio and reserve the correct space before the image loads. CSS aspect-ratio can also be used for responsive containers.

Client-Side vs Server-Side Compression

Server-side image processing (Sharp, ImageMagick, Cloudinary, imgix) is the standard for production pipelines. They process at build time or on-the-fly and can serve format-negotiated responses based on the browser's Accept header — WebP for Chrome/Firefox, JPEG for older Safari.

Client-side compression using the HTML5 Canvas API and WebAssembly is ideal for user-uploaded content, one-off optimization of individual files, and scenarios where you cannot or do not want to upload images to a third-party server. The browser's built-in Canvas.toBlob() method supports JPEG and WebP encoding with adjustable quality, and modern WebAssembly libraries bring near-native compression performance to the browser.

Core Web Vitals Impact

Google's Core Web Vitals measure three aspects of user experience: Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), and Interaction to Next Paint (INP). Image optimization directly affects two of them:

LCP (Largest Contentful Paint): The time until the largest visible content element finishes rendering — almost always an image. Target: under 2.5 seconds. Compress and properly size your hero image, use WebP/AVIF, and preload the LCP image with <link rel="preload">.
CLS (Cumulative Layout Shift): Visual instability caused by elements shifting as the page loads. Images without explicit dimensions cause layout shifts when they load. Target: under 0.1. Always set width and height.

Optimization Checklist

Serve WebP or AVIF with JPEG fallback for older browsers
Compress at quality 75-85 for lossy formats — quality 100 is almost never necessary for web use
Resize images to match their display dimensions — never serve a 4000px image in a 400px container
Use srcset and sizes for responsive images
Lazy-load below-the-fold images; eagerly load the LCP image
Always set width and height attributes to prevent layout shift (CLS)
Preload the LCP image with <link rel="preload" as="image">