No modern image formats

JPEG: photographs, universally supported, no transparency, and the baseline everything else is compared against.

PNG: lossless, supports transparency, and very large for photographic content. Correct for screenshots, diagrams and images with sharp edges; wrong for photographs.

WebP: lossy and lossless modes, transparency, animation. Supported by all current major browsers. The safe default for photographic content today.

AVIF: better compression again, particularly at low bit rates, with transparency and wide colour support. Encoding is slower, which matters in a build pipeline rather than at request time.

SVG: not a raster format at all, and the right answer for logos, icons and diagrams — resolution-independent and usually a fraction of the size.

The `<picture>` element is the mechanism: list sources in order of preference and let the browser take the first it supports.

`<picture><source srcset="photo.avif" type="image/avif"><source srcset="photo.webp" type="image/webp"><img src="photo.jpg" alt="…"></picture>`. A browser that understands neither new format falls back to the `<img>`.

The `<img>` inside `<picture>` is required — it carries the `alt` text, the `width` and `height`, and the fallback. Omitting it produces an image that renders nowhere.

The alternative is content negotiation: an image CDN reading the `Accept` header and returning the best format the client advertises. That keeps the markup unchanged and moves the decision to the server.

Either way, keep the original. Formats change, and re-encoding from a compressed file loses quality that cannot be recovered.

When the image is an icon or a logo, where SVG beats all of them.

When a file is consumed by something other than a browser — an email client, a document generator, a partner feed — where support is genuinely uncertain.

When the image is already small. A 4 KB thumbnail converted to WebP saves a kilobyte, and the build complexity is not repaid.

When the source is a screenshot with text, where aggressive lossy compression in any format produces visible artefacts around the glyphs. Lossless WebP or PNG is the right choice there.

The decision is per image type rather than site-wide, which is why 'convert everything' produces both savings and regressions.

In the Network panel, filter by image and read the `Type` column. A page serving only `jpeg` and `png` has not adopted anything.

Check the response `Content-Type` rather than the file extension. An image CDN doing content negotiation returns WebP from a URL ending `.jpg`, and the extension tells you nothing.

In the console: `[...document.images].map(i => i.currentSrc)` shows which source the browser actually selected from a `<picture>`, which is the only way to confirm the negotiation worked.

Compare total image bytes before and after on a representative page. The saving is the measurement that justifies the work.

Generate the variants in the build or upload pipeline, not by hand. A manual conversion covers the images that existed on the day it ran.

Serve them with `<picture>`, or use an image service that negotiates on `Accept` and leave the markup alone.

Resize before converting. A modern format applied to an oversized image saves a fraction of a cost that should not have existed.

Replace icon and logo PNGs with SVG, which is usually the largest single saving on a page that has many of them.

Set a quality target and check it visually on the images that matter. The defaults of most encoders are conservative, and the savings between 'default' and 'tuned' are substantial.

`images.webp` and `images.avif` report the proportion of images on the crawled pages served in each modern format, and name the ones still delivered as JPEG or PNG.

`images.compression` reports images whose encoding is inefficient for their content, which is the adjacent question of whether the bytes are justified regardless of format.

`images.inventory` and `images.weight` give the per-page list and totals, so the saving available from a conversion is visible rather than estimated.

The checks read the response type rather than the file extension, which is what distinguishes a site already negotiating formats from one that has not started.