Image Optimization Best Practices

The largest available win, almost every time, and the one most often skipped.

An image displayed in an 800-pixel column but exported at 4000 pixels wide carries twenty-five times the pixel data it can show. No format change or quality setting recovers that; the bytes are spent on pixels the browser throws away while scaling.

Check the ratio rather than guessing: browser developer tools show an image's rendered size alongside its intrinsic size, and a Lighthouse audit lists oversized images with the saving in kilobytes. Working out the right numbers covers the per-slot dimensions and how much to allow for high-density screens.

Worth: frequently 50–90% of an oversized image's bytes.

Free in visual terms — you are changing the encoder, not the picture. Google's figures put WebP at 25–34% smaller than comparable JPEG at equivalent SSIM quality and 26% smaller than PNG losslessly, and every current browser reads it.

The rules that cover nearly everything:

• Photographs: WebP lossy.
• Screenshots, line art, anything with hard edges: WebP lossless.
• Logos and icons: SVG if you have the vector — sharp at any size, usually smaller than any raster version.
• Never a lossy format for text or line art, whatever the size saving looks like.

AVIF is smaller again where you can serve multiple formats, at a median 50% against JPEG on MDN's figures. The three-way comparison covers when that extra step is worth the friction.

Worth: 25–35% against JPEG, and often far more against a PNG photograph.

Between 100% and 80% quality a photograph loses a lot of bytes and very little appearance. Below about 60% the file barely shrinks further while artifacts become obvious. So 80% is not a timid compromise, it is where the curve flattens.

Practical notes:

• 80% for web photographs, 90–95% for anything that may be printed or edited again.
• Screenshots do not belong in this discussion at all — keep them lossless.
• Verify on detail, not on flat areas. A before/after comparison over hair, foliage or text tells you something; a comparison over a plain wall does not.
• If a file comes back larger than it started, it was already optimised. Keep the original — the compressor does this automatically and marks the file rather than handing you the worse copy.

Worth: substantial on unoptimised exports, near zero on files that have already been through this once.

Not a size saving — a stability one, and it costs nothing.

MDN puts the reason precisely: including height and width "enables the aspect ratio of the image to be calculated by the browser prior to the image being loaded", which reserves the space and "reduc[es] or even prevent[s] a layout shift when the image is downloaded and painted".

Without them the page reflows as each image arrives — text jumps, someone taps the wrong link, and Cumulative Layout Shift suffers. Set the attributes to the image's intrinsic pixel dimensions and let CSS handle the visual size (max-width: 100%; height: auto). Modern browsers use the attributes purely to compute the ratio, so they do not fight your stylesheet.

Worth: nothing in bytes, a great deal in perceived quality and in Core Web Vitals.

loading="lazy" defers an image until it approaches the viewport. MDN describes the two values plainly: eager "loads the image immediately, regardless of whether or not the image is currently within the visual viewport", while lazy "defers loading the image until it reaches a calculated distance from the viewport".

For a page with twenty images and three visible, that is seventeen requests that may never happen. One attribute, no library.

The trap is applying it to everything. Lazy-loading the hero image delays the very element that Largest Contentful Paint is most likely measuring — web.dev lists img elements among the LCP candidates, and the threshold for a good score is 2.5 seconds at the 75th percentile of page loads. Deferring your largest visible image is therefore a direct, self-inflicted regression, and it is a common one because "lazy-load your images" gets repeated without the exception.

The rule: everything below the fold lazy, the hero eager, and if the framework or plugin applies it globally, exempt the hero explicitly.

Worth: large on long pages; negative if you get the hero wrong.

If you control the markup, srcset with a sizes attribute lets the browser pick from candidate widths, so a phone downloads a 600px file and a desktop with a high-density display downloads a 1600px one.

Three widths is plenty for most sites. Frameworks with an image component and image CDNs do this generation for you; a CMS usually creates variants from your upload, which is why giving it a generous source matters.

If you are hand-writing a single img tag, exporting at 2× the display width and moving on is a perfectly reasonable stopping point — the difference between that and a tuned responsive setup is much smaller than the difference between either and an unresized original.

Worth: meaningful on mobile traffic, which is usually most traffic.

A camera JPG can carry tens of kilobytes of EXIF, sometimes an embedded thumbnail and a colour profile as well. On a 3 MB photograph that is noise; on a 40 KB thumbnail it can be a fifth of the file.

The stronger argument is privacy rather than size. EXIF routinely includes the camera body, the exact timestamp and — for phones and GPS-equipped cameras — the coordinates where the photograph was taken. Publishing that with a picture of your house or your child's school is a genuine disclosure, and it happens by accident constantly.

Three of the compressor's four presets strip metadata by default; the dedicated tool shows what a file is carrying before you decide.

Worth: small in bytes, occasionally significant in consequences.

Being honest about diminishing returns is more useful than a longer list.

Sprite sheets and image concatenation. A real technique under HTTP/1.1, where every request was expensive. Under HTTP/2 and HTTP/3, requests are multiplexed and the benefit is mostly gone — while the cost, a single file that invalidates entirely when one icon changes, remains.

Base64-inlining images in CSS. Saves a request and grows the payload by about a third, blocks rendering while the stylesheet parses, and cannot be cached separately. Occasionally right for a tiny critical icon; usually a downgrade.

Squeezing the last 5%. Once an image is correctly sized, in WebP, at 80%, further tuning yields kilobytes. Time is better spent on the next unoptimised image than on perfecting this one.

Choosing a CDN before fixing your images. A CDN makes delivery faster; it does not make a 4 MB hero appropriate. Fix the asset, then improve the delivery.

For a page you are auditing now:

1. Every image exported at display width (×2 for high-density where it shows).
2. Photographs in WebP, graphics in WebP lossless, logos in SVG.
3. Photographs at around 80% quality; graphics lossless.
4. width and height on every img.
5. loading="lazy" everywhere below the fold; hero explicitly eager.
6. srcset where you control the markup.
7. Metadata stripped on anything public.
8. Hero under 200 KB, page total under 1 MB.
9. Re-run the audit and check the LCP element is what you expected.

Items 1 and 2 will usually deliver most of the improvement. If you only have twenty minutes, do those two across every image on the page rather than all nine on one image.