Does switching to AVIF or WebP always make images faster?

No. A format can reduce transferred bytes, but the result also depends on the image, encoder settings, rendered dimensions, decoding on the device, and cache hits. Start by encoding the same image at the same display size, comparing file size and visible artifacts, then verify fallback and cache behavior. web.dev image performance guidance

Compare content and quality, not format labels

AVIF is a specification for storing AV1 image data in a HEIF-based file format. It supports HDR, wide color gamut, transparency, and multiple bit depths, but a file extension alone does not tell you the encoder settings or decoding cost on a particular browser. AOMedia AVIF specification v1.2.0 WebP supports lossy and lossless compression and transparency. Google’s WebP overview

Photographs are useful candidates for comparing lossy encodings. In screenshots, diagrams, or images with fine text and lines, smearing and colored edges may be more visible at the same settings. Inspect both a small thumbnail and a large hero at their actual rendered sizes. Choose based on observed quality and transferred bytes rather than applying one format everywhere. web.dev on compression and formats

Example: change one product hero safely

Suppose a product photo is displayed at 800 pixels wide. Prepare JPEG, AVIF, and WebP candidates at the same dimensions, then inspect not only the photographic texture but also any price text and sharp edges. Measure bytes, actual mobile transfer size, the hero’s LCP, and decode behavior on supported devices. If AVIF is smaller but conversion delays the first request or adds device cost, WebP or the existing JPEG may work better. These are things to measure, not a rule that one format always wins.

For browser fallback, a <picture> element can list AVIF and WebP sources and contain an <img> with a JPEG fallback. Put alt, width, and height on the <img>. If display widths vary, use srcset and sizes as well so a phone does not receive an unnecessarily large original. web.dev picture and responsive image examples

Check caches when negotiating on the same URL

If a server chooses AVIF, WebP, or JPEG at one path based on the request’s Accept header, shared caches must distinguish those responses. In a general HTTP setup, send Vary: Accept correctly and verify that the cache key actually accounts for the variants. web.dev on Accept negotiation

Cloudflare’s Vary for Images feature parses Accept and stores format variants separately. Current documentation limits availability to Pro, Business, and Enterprise plans; the origin must send Vary: Accept and serve the configured variants. If the configured type is not served by the origin, the response may not be cached and can show BYPASS. These are Cloudflare-specific conditions; do not assume every CDN behaves the same way. Cloudflare Vary for Images documentation

A pre-release check

  • 1. Choose real assets: a photograph, an image with text or fine lines, and a transparent image if you use one. Compare candidate formats at the same dimensions and intended quality.
  • 2. Check the HTML fallback and responsive sizes, and confirm the response Content-Type matches the file actually returned.
  • 3. Request the image with at least two different Accept headers. Check the returned bytes’ format, Vary, and cache status; measure the first request separately from a repeat request.
  • 4. Keep only useful variants. Every additional size-and-format combination can add cache entries and origin fetches.

Measure pixel dimensions, network transfer, and cache efficiency alongside compression. A smaller file by itself does not guarantee better LCP or a faster-feeling page. web.dev image performance guidance

Sources