Images are served in older, heavier formats
What this check looks for
‹count› image(s) are served as JPEG, PNG, BMP or TIFF where AVIF or WebP would usually carry the same picture in far fewer bytes.
Why it matters
This is one of the few optimisations with no visual cost and no design decision attached: the same image, noticeably fewer bytes, on every visit.
When the check passes, your report says: “Images are served in modern formats such as AVIF or WebP”.
What it costs your score
When this check fails it removes 5 points from your Performance score, before the status, confidence and repeat multipliers are applied. Performance carries a weight of 8 in the overall score.
It shares the performance.assets family ceiling of 25 points: however many findings that family produces, together they cannot remove more than that from Performance. One underlying problem showing up in several places is still one problem.
- Severity
- low
- Default confidence
- confirmed
- Status when triggered
- warn
- Deduction
- 5 points
- Family cap
- performance.assets · 25
- Category
- Performance
- Module
- Perf assets
- Fix owned by
- user
- In the ruleset since
- 2026.09
How to fix it
Serve images as AVIF or WebP, with the original format as a fallback.
The files listed above are in formats a modern encoding would usually shrink substantially, at no visible cost.
Convert the images this finding lists to AVIF, and to WebP as a second option.
Offer them with
<picture>and<source type>so the browser picks what it supports and falls back to the original file otherwise.Keep the fallback. A
<picture>with only AVIF sources and no<img>renders nothing where AVIF is unsupported.If your CDN or image service supports format negotiation on
Accept, turn it on — that converts every image at once, including ones added later.Re-check quality at the new settings, and compare the converted file against the original before shipping it: on flat graphics and very small images the conversion sometimes gains nothing.
How to confirm it worked
Re-run this scan and confirm the legacy-format count has dropped.
curl -sSI -H 'Accept: image/avif,image/webp,*/*' https://‹host›/path/to/image — check the
content-typethat comes back
A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.
Remediation by platform
<picture>
<source srcset="/photo.avif" type="image/avif">
<source srcset="/photo.webp" type="image/webp">
<img src="/photo.jpg" width="800" height="450" alt="">
</picture>Order matters: the browser takes the first
<source>whosetypeit can decode, so put AVIF before WebP. The<img>is both the fallback and the element that carriesalt,widthandheight.
Technical detail
Images in legacy formats: ‹count›.
‹summary›
‹detail›
**How this was measured, and what it could not see.** We fetched the page and then the subresources its HTML declares, and read what the server sent back. No browser was involved, so nothing here depends on how fast our machine is — but equally, **a resource that a script loads after the page arrives is invisible to this check**. A page that assembles its own asset list at runtime will look lighter here than it is. The number of subresources the page declared, and how many of those we asked about, are both stated in the page-weight finding; where they differ, this section examined a prioritised sample rather than the whole page.
**We do not tell you how much a conversion would save, and that is a deliberate omission.** Measuring it means re-encoding each image and comparing, which needs an image codec we do not ship and will not add for a figure that only ranks one opportunity against another. What is reported instead is exactly what was observed: the format the server declared and the size it sent. A published ratio from a vendor is not a measurement of *your* images, and presenting one as if it were would be the kind of plausible number this report avoids.
AVIF and WebP are supported by every current browser. AVIF generally compresses best, WebP is the safer floor, and <picture> lets you offer both with the original as a last resort — the browser takes the first source it can decode, so no visitor is left without an image. SVG is not reported here: for line art it is already the right answer.
Two caveats worth knowing before converting everything. AVIF encoding is slow, which matters for a build pipeline but not for the visitor. And for very small images the format overhead can outweigh the compression win, so measure your own files rather than assuming.
Standards and references
Test this on your domain
Run the check that produces this finding, on its own, against any domain.