Image Optimization Tips for Web (Complete 2026 Guide)

A friend's portfolio site was getting complaints — "your site takes forever" — and he'd been quoted £400 for a "performance audit". Before he paid it, we opened DevTools together, sorted the Network tab by size, and found the culprit in under a minute: his homepage hero was a 7.4MB photograph, straight from the camera, 6000 pixels wide, displayed at 1200. Ten minutes of resizing and compressing later, the page loaded in under two seconds on 4G and the audit money stayed in his pocket. Image optimization is the highest-return ten minutes in web performance, and this guide is the complete version of that kitchen-table session.

Step 1: Find your actual heaviest images (don't guess)

DevTools → Network tab → filter Images → sort by size → reload. The offenders are almost always a handful of files, almost always photos, almost always the hero. Fix the top five before touching anything else — optimization effort should follow bytes, and the bytes are shockingly concentrated. (PageSpeed Insights gives you the same list with scores attached, free.)

Step 2: Resize to display size — the step that does the most

The cardinal waste: shipping 6000 pixels into a 1200-pixel slot. The browser downloads everything and displays a fifth of it. Resize to roughly the displayed width — 1600px generously covers most full-width slots on retina screens; 800px covers content images — and the file often drops 70% before compression even starts. Rule that prevents regret: keep originals in a folder; scale down copies, never up.

ADVERTISEMENT

Step 3: Compress at quality 70–80

JPG quality 75 is visually indistinguishable from 100 for nearly everyone and roughly a third of the size. Run resized images through a browser compressor (local processing — files never upload, relevant for client work). Targets that keep pages honest: heroes under 300KB, content images under 150KB, thumbnails under 40KB. Below quality ~60, photos start visibly smearing; the destination's demands occasionally force it, your defaults shouldn't.

Step 4: Pick formats like it's 2026

• WebP for photos and most web images — ~30% smaller than JPG at equal quality, universal browser support now. A converter makes this a batch job.
• PNG only for screenshots, logos, and sharp-text graphics. A photo saved as PNG is the classic accidental 5MB.
• SVG for icons and logos — infinitely sharp, tiny, and skips this whole pipeline.
• AVIF where your tooling supports it — smaller still, worth adopting when convenient rather than fighting for today.

Step 5: The HTML layer — two attributes, one warning

loading="lazy" on below-the-fold images defers them until needed — one attribute, real savings on image-heavy pages. Width and height attributes on every image prevent layout shift (the jump-around that Core Web Vitals punishes). The warning: never lazy-load the hero — it delays the first thing visitors see, converting your optimization into a regression. This mistake is epidemic because "lazy-load everything" advice copies well.

Step 6: Test where your visitors actually are

Your fibre-connected desktop lies. Test on a mid-range phone over mobile data, or throttle to "Fast 4G" in DevTools — that's the median visitor in most markets, and it's where the 7.4MB hero went from "slightly slow" to "complaints". PageSpeed Insights' mobile score is the number to watch; its Largest Contentful Paint metric is usually your hero image telling on itself.

What optimization honestly can't fix

A gallery of forty images is forty requests however small; curate to the eight that earn their place. Blur is permanent — compression makes bad photos smaller, not better. And image weight is only the largest slice of page speed, not all of it; if pages remain slow after the images are clean, the remaining suspects are fonts, scripts and hosting, in that order. But do the images first: it's the cheapest fix with the biggest slice. The broader free toolkit for these jobs lives in our image tools guide.

Optimization that moves Core Web Vitals

One site we helped went from 2.8s LCP to 1.4s by doing three image things: hero to 1600w WebP, thumbnails to 800w, and one background video removed.

Check this week

• Find page with >1.5MB images (DevTools → Network)
• Convert hero to WebP
• Lazy-load below-fold images

Frequently Asked Questions