Tutorial · images · Published 2026-08-15 · 4 min read
How to compress images for the web
Compress images for the web in the right order: measure current size, pick a format, resize to render size, apply lossy balance, strip metadata, and automate.
Why compression is a system, not a shortcut
Images make up most of the bytes on most commercial pages. A marketing site with a 1 MB hero and a few product shots downloads more from its images than from all scripts and styles combined. Dropping the total image payload is the fastest measurable improvement to LCP and bandwidth.
This tutorial works through a repeatable pipeline: measure current sizes, choose a format, size to the render layout, apply a lossy balance, strip metadata, then wire it into the build so the next upload does not regress.
Step 1: Measure current file sizes
Before changing anything, record the baseline so you can later prove the win.
- Open the page in devtools and list the images with their file sizes.
- For each large image, note the loaded bytes and the width the layout renders it at.
- Record total page weight, image count, and LCP from the same run.
Measurement matters because a 2500px-wide original in a 640px hero column is oversize before compression even starts. A tool inspection is worth more than the file on disk by itself.
Step 2: Choose the output format
Fit the format to the image content after sizing:
- Photographs and gradients: JPEG or a modern equivalent such as WebP or AVIF with lossy compression.
- Screenshots, line art, and flat transparency: PNG or lossless WebP, which keeps crisp edges.
- Logos and icons: SVG, covered in the SVG vs PNG decision aid.
- The modern default is WebP: it beats JPEG by 25 to 35 percent at equal quality, per the format table in the image optimisation guide.
Step 3: Size to render dimensions
Resize the image to the largest size the layout actually uses, at the device pixel ratio the site serves. A 1600px hero is overkill for a 600px slot; the target is render width times the pixel ratio, commonly 1x for icons and 2x for photo heroes.
Resize first, then compress. Compressing a 4000px file that never renders wastes encoding time and keeps none of the visual benefit.
Step 4: Apply the lossy balance
Start at quality 75 to 85 for photographic JPEG and WebP, then step files down until the visual difference becomes visible in a side-by-side. Come back one step and keep that number for every image in the library.
Example before and after for a typical 4000px hero:
| Stage | File size | Note |
|---|---|---|
| Original | 2.4 MB | phone photo, 4000px |
| Resized to 1600px | 640 KB | downscaled only |
| WebP quality 80 | 210 KB | no visible difference |
| WebP quality 70 | 155 KB | final ~93 percent smaller |
A 2.4 MB hero lands around 150 to 250 KB with no visible loss on a phone screen.
Step 5: Strip metadata
Remove EXIF, colour profiles when the asset renders correctly without them, timestamps, and camera data. Tools such as cwebp -metadata none and EXIF removal in a CMS export drop a few percent and stop leaking location data. Metadata is rarely needed for render; image quality is unchanged.
Step 6: Verify and automate
- Re-run the earlier measurement and confirm total page weight and LCP improved.
- Spot-check the images that slimmed most for visible artefacts.
- Enforce a budget: treat any image above, say, 500 KB as a build warning, and convert in CI instead of relying on manual memory.
Automation earns more than any single manual save. Once the pipeline exports photos as WebP at quality 78, the next upload passes through an unchanged quality gate. Serve the result from cache per the CDN guide, and keep the render sizing and srcset details from the image optimisation guide.
When to involve a professional
If the CMS stores raw uploads or the site serves user-generated photos at scale, let a developer script the conversion to keep originals intact and derivatives current. The remaining steps (sizing and srcset) are covered in the linked guides above.