Size and format must be generated per use case

What it is

One source image is not one delivery. CSS pixels on screen, device pixel ratio, and which codecs the decoder supports jointly decide which file to send. Generate size and format per use case means emitting, for each display slot, matching width, height, density, and encoding (AVIF / WebP / JPEG, and kin), then letting runtime pick via srcset, sizes, or an equivalent manifest. Feeding the same 4000-pixel original to an avatar and to a full-bleed hero wastes bytes and decode, not “not enough quality.”

Why it happens

Decode is billed in encoded pixels: width × height × channels, times DPR. An avatar that displays at 80 CSS pixels still decodes a 2000-pixel edge on CPU/GPU, then throws the extra samples away. Format sets compression and whether hardware decode is available: AVIF is often smaller than JPEG for the same content, but older devices may not decode it. srcset lists candidates; sizes tells the engine how wide the slot is in the current layout; the engine picks the nearest candidate for DPR and slot width. With no per-slot candidates, it can only pick “the one file,” whether or not it fits.

Use case also includes crop. A list thumbnail needs a center crop; a hero needs the composition. Downscaling without cropping sends a too-small-to-read full frame into a tiny slot, costing bytes and losing the subject.

Where it stops holding

User-upload preview cannot wait on the full pipeline; local downscale first, variants later in the background, is legitimate. Vector icons and SVG illustration do not use raster srcset. Print and poster export want physical resolution, not slot width. A rare internal admin page may cost more to maintain variants than to ship a few originals. Live video and realtime canvas frames are not pre-generated files.

Applying it

• Declare CSS width, max DPR, and allowed codecs per slot, and emit matching files at build; components must not hardcode one original URL.
• Put both srcset and sizes (or the client equivalent) in markup so the engine uses slot width, not a viewport guess.
• Emit a cropped size for thumbnails; do not downscale the hero into the list.
• Verify by capturing requests on 1x and 3x, in a narrow list and a wide hero: encoded edge length should sit near slot × DPR. Decode time should drop with the tier, not stay stuck on one large file.

Related

• Same group: R3.07.2 Undeclared dimensions cause layout jump · R3.07.3 Autoplay consumes bandwidth and attention · R3.07.4 Off-viewport media is deferred; in-viewport media is prioritized · R3.07.5 Placeholder color close to the final image reduces pop · R3.07.6 Media fallback chains must cover decode failure and unsupported formats
• Adjacent: J2.05 Decorative Images · R3.04 Performance budgets
• Search terms: srcset · image variants · decode