Image Optimisation for the Web: WebP, AVIF, Size and Quality

Optimise for the image’s job before choosing a codec

A hero photograph, SVG logo, interface screenshot, editorial diagram and transparent product cutout have different needs. Keep vector artwork as SVG when appropriate; use raster formats when the content is inherently raster or when the delivery context requires it. AVIF and WebP are powerful choices for many raster assets, but they are not replacements for understanding the visual content.

AVIF versus WebP is a visual test, not a winner-takes-all decision

MDN’s current format guide describes AVIF as a modern format with strong lossy/lossless compression, alpha, HDR and wide-gamut capabilities, while WebP also supports lossy/lossless compression, transparency and animation with broad modern-browser support. AVIF can achieve excellent compression, but progressive rendering, encoder cost and image-specific artefacts can affect the practical choice.

Create a visual acceptance threshold for the asset type. A tiny byte reduction is not valuable if the UI text becomes soft, the logo edge rings or a gradient shows distracting banding.

Sending the right dimensions often matters more than changing the extension

A browser displaying a 400px card does not normally need a 2400px source for every user. Responsive image markup allows multiple width candidates so the browser can choose a resource closer to the rendered requirement and device density.

Use only candidates that the design can actually select. Generating dozens of near-identical sizes adds storage and production complexity without meaningful transfer savings.

Use `srcset` and `sizes` as part of the layout contract

Width-descriptor `srcset` tells the browser which intrinsic source widths exist. `sizes` describes the expected rendered width under layout conditions. With that information plus device pixel ratio and browser heuristics, the browser can select an appropriate candidate.

Use art direction when the composition needs to change

Sometimes resizing the same source is not enough. A wide hero with a small subject can fail on mobile because the subject becomes unreadably small. The `<picture>` element can provide different crops or source choices for different media conditions and formats.

• Wide environmental crop on desktop.
• Tighter crop on tablet.
• Portrait or square subject-led crop on mobile.
• Keep alt text meaningful for the actual information conveyed.

Give the browser intrinsic dimensions to reserve layout space

Current MDN guidance recommends explicit `width` and `height` attributes because the browser can calculate the image aspect ratio before download and reserve the required space. CSS can still render the image responsively; the attributes provide intrinsic geometry rather than forcing a fixed visual size.

This is especially important with lazy-loaded media because an unloaded image without usable geometry can contribute to disruptive layout changes.

Do not lazy-load the image that is likely to become LCP

web.dev explicitly warns against lazy-loading the LCP image because it delays resource discovery/loading. A critical hero should normally be discoverable directly from the initial HTML and load eagerly/default. If it is truly the priority resource, `fetchpriority="high"` can be used selectively.

Priority is finite. Marking many images high priority removes the browser’s ability to make useful distinctions, so reserve that hint for one or very few critical resources.

Preload only when discovery is genuinely late

If the critical `<img>` is already in initial HTML, correct markup and priority may be enough. Preload is more useful when the browser would otherwise discover the image late, such as a CSS background or JavaScript-injected asset. web.dev’s responsive preload guidance supports `imagesrcset` and `imagesizes` but warns against preloading multiple format alternatives because that can cause unnecessary downloads.

A production image pipeline for portfolios and marketing sites

1. 01
   Preserve the high-quality master

   Keep the source asset outside the runtime optimisation outputs.

2. 02
   Define use-specific crops

   Create different compositions for hero, card, article or social use when needed.

3. 03
   Measure the real maximum rendered width

   Do not export 4K because it feels safe.

4. 04
   Generate a small useful width ladder

   Match actual component and density needs.

5. 05
   Compare AVIF/WebP visually

   Inspect edges, gradients, skin, grain, type and texture.

6. 06
   Wire `srcset` and `sizes`

   Give the browser accurate source candidates and layout information.

7. 07
   Declare intrinsic dimensions

   Reserve layout space before the file arrives.

8. 08
   Set page-level loading priority

   Eager/priority for real LCP candidates; lazy for below-the-fold media.

9. 09
   QA network selection and visual result

   Confirm which candidate was actually downloaded and whether the rendered image still meets the design bar.

Common web-image optimisation mistakes

• Converting everything to AVIF and assuming the work is finished.
• Sending desktop-master dimensions into small mobile cards.
• Providing `srcset` but inaccurate `sizes` hints.
• Lazy-loading the hero/LCP image.
• Giving every image high fetch priority.
• Omitting width/height and causing avoidable layout movement.
• Failing to inspect compression artefacts in UI screenshots and typography.
• Forcing the same image file to serve page content, art-direction and social-preview needs.