Image optimization for the web: formats, compression and sizing

Images are consistently the largest contributor to page weight, and the fix is rarely "make the JPEG a bit smaller" — it is usually a sequence of decisions made in the wrong order.

Decide the format first

• **Photographs, screenshots, textured content** — WebP first, JPEG as a fallback for very old clients. WebP is typically 25-35% smaller than JPEG at equivalent visual quality.
• **AVIF** — even smaller than WebP in many cases, but encoding is slower and support, while now broad, still lags WebP in some tooling.
• **PNG** — reserve for images that genuinely need lossless output or hard-edged transparency (icons, logos with flat color and sharp edges).
• **SVG** — anything that is actually vector data: icons, logos, illustrations built from shapes. Never rasterize something that started as vector art.
• **GIF** — essentially obsolete for anything except tiny looping animations; an actual video (muted, autoplaying, looped) is smaller and higher quality for the same content.

Resize before you compress

A 4000×3000 photo displayed at 800×600 on the page is wasting over 90% of its pixels regardless of compression quality. Determine the largest size the image will actually render at (accounting for retina displays, so roughly 2x the CSS size), and resize to that before touching compression settings. This single step usually saves more bytes than any quality slider.

Serve multiple sizes with srcset

<img
  src="hero-800.webp"
  srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1600.webp 1600w"
  sizes="(max-width: 600px) 100vw, 800px"
  alt="Product photo"
/>

The browser picks the smallest file that satisfies the display size and pixel density, so mobile visitors never download the 1600w version.

Compression quality that actually holds up

For WebP/JPEG photographs, a quality setting around 75-85 is where the size-to-visual-quality curve flattens out — pushing higher rarely improves perceived quality but does increase file size substantially. Flat illustrations and screenshots with large solid-color areas tolerate lower settings than photos of faces or complex textures, where artefacts are more visible.

Strip metadata

EXIF data (camera model, GPS coordinates, timestamps) and color profile chunks add bytes with zero visual benefit for web delivery, and GPS data is a real privacy leak if the image was taken on a phone. A compression pass should always drop this unless the metadata is specifically needed downstream.

SVGs need optimization too

Exported SVGs from design tools are full of editor-specific metadata, unnecessary groups, and needlessly precise decimal coordinates. Running one through an optimizer typically cuts file size by 40-60% with zero visual difference — remove empty groups, round coordinates to 2-3 decimal places, and strip editor namespaces and comments.

Lazy-load what is off-screen

`loading="lazy"` on `<img>` defers requests for images below the fold until the user scrolls near them, which matters more for total page weight on first paint than any single compression setting.

Favicons and icons: generate the full set once

Modern platforms expect several sizes and formats (16×16 and 32×32 ICO, 180×180 Apple touch icon, various PNG sizes for Android). Generate the whole set from one source image once, rather than manually resizing each variant by hand and inevitably missing one.

A rough checklist

• Format chosen based on content type, not habit.
• Resized to actual display dimensions (×2 for retina).
• Compressed at 75-85 quality for photographic content.
• Metadata stripped.
• SVGs optimized, not just exported.
• Lazy-loaded below the fold.