Images Not Served as WebP or AVIF: Verify Actual Formats

In one paragraph

Images not served as WebP or AVIF means the source-markup heuristic found legacy image filenames without a recognised modern-format filename. It does not prove visitors receive JPEG or PNG: an image service may negotiate another format at the same URL. Inspect actual responses, compare suitable encodings at realistic quality and dimensions, and preserve fallbacks where your supported consumers require them.

Why it matters

Image transfer size can dominate a page's download and contribute to LCP when a prominent image is the largest visible content. Modern formats can reduce bytes at comparable perceived quality, but results vary by image, encoder, quality setting, transparency, and animation.

Format choice is only one part of image delivery. An oversized AVIF can still waste bandwidth, while a correctly sized and well-encoded JPEG can be reasonable for a particular workflow. Compare outputs rather than promising a universal percentage saving or converting every asset indiscriminately.

Browser and non-browser consumers differ. A picture element can offer alternatives, while an image service can negotiate through Accept and report the selected Content-Type. A filename extension alone cannot reliably identify the response bytes.

How WebAuditOS evaluates this finding

The supplied rule reads img src, or data-src when src is absent, from served HTML. Recognised JPEG or PNG URLs with no recognised WebP or AVIF URL warn. At least one recognised modern image can pass the whole page, as can no recognised legacy image. No eligible image or unparseable HTML is not graded.

It does not inspect picture source candidates, srcset, CSS backgrounds, negotiated content types, file quality, or byte size. A correct modern-source picture with a JPEG fallback can warn, and one tiny WebP can mask many large JPEGs. Use the result as a prompt to verify, not as proof of poor delivery.

How to fix it

1. Inspect a fresh browser load in the Network panel. Check selected image URLs, response Content-Type, transferred bytes, intrinsic dimensions, displayed size, and request priority. Separate visible critical images from below-the-fold assets.
2. Confirm existing image-service behaviour before changing files. A .jpg URL serving image/avif is already using AVIF for that request. Test supported clients and cache variation rather than renaming files merely to satisfy the heuristic.
3. Compare encodings for representative content. Assess text in screenshots, gradients, photographs, transparency, colour, and animation at actual display sizes. Pick settings that preserve the intended visual result and a manageable encoding workflow.
4. Produce responsive dimensions, not just new extensions. Use suitable srcset and sizes or a framework image pipeline so a phone does not download an unnecessarily large desktop asset.
5. Where format alternatives are useful, a basic pattern is:

<picture>
  <source srcset="/photo.avif" type="image/avif">
  <source srcset="/photo.webp" type="image/webp">
  <img src="/photo.jpg" width="1200" height="800" alt="Descriptive text for the actual photo">
</picture>

Replace the example content and ensure every file exists. Use context-appropriate alt text; a decorative image may need an empty alternative instead. The documented scanner can still warn on this valid fallback pattern.

6. For negotiated delivery at one URL, configure cache handling for the relevant Accept variants using your platform's supported design. Prevent a cached unsupported format from being served to the wrong consumer.
7. Keep critical image discovery prompt and reserve correct dimensions. Do not lazy-load the actual above-the-fold LCP image, while preserving appropriate loading for distant media.
8. Test browser rendering and any email, sharing, or document-processing consumers that use the assets. Rescan, but judge improvement by actual response bytes, visual quality, and loading behaviour.

What the fix can break

Aggressive encoding can damage fine detail or gradients. A smaller file that visibly harms product imagery is not automatically an improvement.

A new format can affect non-browser consumers, content workflows, or unsupported older clients. Keep an appropriate fallback or separate delivery path based on actual requirements.

Incorrect cache variation can make failures appear intermittent. A picture element or established image service can simplify delivery, but still needs validation. Do not add an irrelevant modern image just to turn a source heuristic green.

Questions

Why does the scanner warn when our CDN serves AVIF?

It inspects filenames in initial img references, not negotiated response types. Verify Content-Type and actual bytes in the browser.

Is a JPEG fallback inside picture wrong?

No. It is a normal compatibility pattern. The documented checker does not inspect the alternative source elements.

Should AVIF always replace WebP?

No universal choice fits every asset and consumer. Compare quality, size, processing, and support for your workflow.

Which related checks help?

Review responsive images, LCP, and the Core Web Vitals guide.