The biggest saving is almost always dimensions
The most common and most expensive mistake is serving an image far larger than it will ever be displayed. A photograph straight from a phone is around 4,000 pixels wide. Displayed in a 600-pixel content column, more than 95% of those pixels are discarded by the browser after the user has already paid to download them.
The correct target is roughly twice the display width, which covers high-density screens. A 600-pixel column wants a 1,200-pixel image. Beyond 2× the visual improvement is effectively undetectable while the file size continues to grow with the square of the dimension - going from 2× to 3× costs more than twice the bytes for nothing.
Practical maximums for most sites: hero images 1,920 pixels wide, content images 1,200 to 1,600, thumbnails 300 to 600. If you need several sizes, generate them and let srcset pick.
<img src="photo-800.webp"
srcset="photo-400.webp 400w, photo-800.webp 800w, photo-1600.webp 1600w"
sizes="(max-width: 700px) 100vw, 700px"
width="800" height="533" alt="...">Choosing the format
| Format | Use for | Relative size |
|---|---|---|
| SVG | Logos, icons, diagrams, line art | Usually tiny; scales infinitely |
| WebP | The default for photographs and most images | 25-35% smaller than JPEG |
| AVIF | Where you can afford slower encoding | A further 20-30% smaller than WebP |
| JPEG | Fallback and email attachments | Baseline |
| PNG | Screenshots, sharp edges, transparency | Large for photos; correct for UI |
WebP is supported by every current browser and is the sensible default. AVIF compresses better still but takes considerably longer to encode, which matters for user-uploaded content and not at all for a fixed set of site assets.
The mistake worth naming: saving a screenshot as JPEG. JPEG's compression is designed for photographic gradients and produces visible ringing around sharp text edges. Screenshots belong in PNG or WebP.
Quality settings and diminishing returns
JPEG and WebP quality settings are frequently left at 100, which roughly doubles the file for a difference nobody can perceive.
The useful range is 75 to 85. At 85, most photographs are visually indistinguishable from the original at typical viewing sizes. At 75, differences are detectable only under close comparison. Below 70, artefacts appear in skies, gradients and around edges.
One property to respect: lossy compression is not reversible and it compounds. Every save-and-edit cycle degrades the image further. Keep a lossless master and export lossy copies from it, rather than repeatedly editing the exported version.
What this does to Core Web Vitals
Google measures three things, and images affect two of them directly.
Largest Contentful Paint is usually the hero image. It is the metric images dominate, and the fixes are to reduce the file, serve a modern format, and remove anything delaying its discovery. Do not lazy-load it - loading="lazy" on the LCP element actively delays the metric it is measured by. Add fetchpriority="high" instead.
Cumulative Layout Shift is caused by images without dimensions. The browser does not know how much space to reserve, so the page reflows when each image arrives and the reader loses their place. Always set width and height attributes - CSS can still make the image responsive, and the attributes give the browser the aspect ratio it needs to reserve space.
These two attributes cost nothing and fix the majority of image-related Web Vitals problems. They are more valuable than most of the optimisation work people do instead.
Lazy loading, correctly
loading="lazy" tells the browser not to fetch an image until it is near the viewport. On a long page with many images, this can eliminate most of the initial download.
The rule is straightforward: lazy-load everything below the fold, never anything above it. Applying it universally - which several popular plugins did by default - delays the hero image and makes LCP worse. Anything visible without scrolling should load eagerly.
The rest of the list
- Strip metadata. EXIF blocks can add tens of kilobytes, and camera photographs carry GPS coordinates you may not want published.
- Serve from a CDN. Geographic proximity matters more for large files than for small ones.
- Cache aggressively with content-hashed filenames, so a year-long cache time is safe.
- Reconsider decorative images. The fastest image is the one you did not include. A stock photograph that adds nothing is pure cost.
- Use CSS instead where you can. Gradients, shapes and simple patterns render natively at no download cost.
- Compress SVG. It is text, so gzip or Brotli cuts it by 60-80% - but check your server actually compresses
image/svg+xml, which is often missing from the default list.
A workflow that keeps it under control
The reason sites regress is that optimisation is done once, by hand, and then forgotten as content is added.
For a site with a build step, put image processing in the pipeline so every image is resized and converted automatically. For a CMS, use a plugin or an image CDN that transforms on request from a URL parameter - this is the most robust option, because it handles images uploaded by people who will never think about file size.
For occasional manual work, resizing and converting locally in the browser avoids uploading photographs to a third party. Our image converter does that, and strips EXIF as a side effect of re-encoding.
Frequently asked questions
WebP as the default - universally supported and 25-35% smaller than JPEG. AVIF where the extra 20-30% is worth slower encoding, typically for a fixed set of site assets rather than user uploads.
80 to 85 for photographs. Quality 100 roughly doubles the file for no perceptible gain. Below 70 artefacts become visible in gradients and around edges.
No. It helps for images below the fold and hurts for the hero image, where it delays Largest Contentful Paint. Load above-the-fold images eagerly with fetchpriority="high".
Marginally, for image search. Descriptive filenames and accurate alt text help more than any other image SEO measure - and alt text is a genuine accessibility requirement regardless.