Responsive variants

Core elements for responsive variants

Four axes typically define responsive variants: size, density, format, and crop. Size variants (e.g. 400w, 800w, 1200w) target different layout slots across breakpoints. Density variants (1x, 2x, 3x) serve sharper images to high‑DPR screens without oversupplying pixels to standard displays. Format variants (AVIF, WebP, JPEG, PNG) address codec support and compression efficiency. Crop or art‑direction variants adjust composition for aspect ratios or focal priorities, such as a tighter vertical crop for mobile while retaining a wider landscape for desktop hero placements.

Quality and encoding parameters round out the picture. Lossy quality targets (e.g. q=40–60 for AVIF/WebP or q=70–85 for JPEG, depending on content) help balance byte weight against artefacts; chroma subsampling and smoothing settings further tune results. Metadata policies matter: stripping non‑essential EXIF/IPTC reduces overhead, while preserving orientation and colour profiles prevents visual regressions. Delivery infrastructure—most often an image CDN—generates the matrix of variants on demand and handles caching, while HTML attributes (srcset/sizes/picture) expose the candidates to the browser’s selection algorithm.

Definition and scope

Responsive variants refer to alternative encodings of a single asset that a client can choose among, rather than a single, fixed file. They exist to align delivered bytes with the rendered slot: the image’s CSS size, the device’s pixel density, the supported codecs, and sometimes the page’s media conditions. The scope includes author‑defined client selection via HTML (<img srcset> and <picture>), as well as server‑driven selection informed by request headers or Client Hints. It excludes unrelated techniques like lazy loading or placeholder strategies, which affect when images load rather than which resource is fetched.

Responsive variants can apply to both content images and decorative assets. For content images, variants should preserve semantic equivalence; art‑direction changes may adjust framing without changing meaning. Decorative images (e.g. backgrounds) often use CSS media queries or image-set(), which are conceptually similar, but their selection logic differs and does not influence SEO signals directly. In all cases, the aim is to avoid over‑fetching pixels while safeguarding clarity and composition across the site’s breakpoints and devices.

How browsers choose which responsive image resource to fetch and display when multiple variants are provided

Picture, type, and media first

When <picture> is used, the browser scans <source> elements in order and selects the first whose media condition matches and whose type is supported (e.g. type="image/avif"). Only after choosing a source does it evaluate that source’s srcset. This mechanism enables format switching (AVIF → WebP → JPEG fallback) and art direction (different images per breakpoint), while keeping network requests to a single final candidate. If <picture> is absent, the browser uses the <img>’s srcset directly or falls back to src if no candidates fit.

Width vs density descriptors

With width descriptors (w), the browser computes the rendered slot size in CSS pixels using the sizes attribute (defaulting to 100vw if omitted), multiplies by the device’s DPR, and chooses the candidate whose intrinsic width best meets the requirement, usually the smallest width ≥ needed. With density descriptors (x), the browser knows the element’s CSS pixel size and multiplies by the chosen density (1x/2x/3x) to pick an appropriate candidate; sizes is ignored in this mode. Other factors—user Save‑Data preference, memory pressure, and zoom—may nudge selection but do not change the basic algorithm.

Re‑selection behaviour

Browsers select a candidate during layout and may re‑evaluate when viewport size, DPR (e.g. moving a window between displays), or media queries change. They tend to avoid down‑switching to lower‑resolution variants after a higher‑resolution has been fetched to prevent visible degradation. Preload directives (link rel=preload with imagesrcset/imagesizes) influence early selection, ensuring the correct variant is fetched before render blocking paths resolve, which is impactful for hero images affecting LCP.

Impact on performance and SEO

Right‑sized, modern‑format variants can reduce image transfer by 40–80% compared with serving a single large JPEG to all users, particularly on high‑density mobile where oversupplying pixels is common. This translates into faster start render and improved Largest Contentful Paint, especially for prominent hero images. Smaller payloads also lower data costs and battery usage. Conversely, poor variant sets—too few widths, no modern formats, or mismatched sizing—inflate bytes and degrade responsiveness under constrained networks, increasing abandonment and depressing revenue metrics linked to speed.

SEO gains are indirect but material. Faster pages support stronger Core Web Vitals, which Google states are ranking signals. Properly implemented responsive images reduce CLS by including width and height (or aspect‑ratio), ensure high‑DPR users see crisp imagery in SERP previews, and help crawlers index representative images without unnecessary variants clogging crawl budgets. Alt text, captions, and structured data remain the primary image SEO levers; responsive variants preserve those signals while avoiding duplicate‑content dilution by using consistent canonical URLs or parameter patterns within sitemaps.

Selection logic pitfalls

A few recurrent issues undermine the browser’s choice. The most damaging is an inaccurate sizes attribute with width‑based srcset: if sizes overestimates the rendered slot (e.g. 100vw where the image is actually ~50vw on desktop), the browser will consistently over‑download. Using density descriptors for fluid images is another trap; x‑based srcset suits fixed‑size UI icons, not flexible content images. Format switching errors occur when <source> order is wrong (e.g. WebP before AVIF without type hints) or when fallbacks are missing, leading to broken images in older browsers.

Other pitfalls include mixing width and density descriptors in one srcset, providing gaps in width coverage that force big jumps (e.g. 480w → 1200w), and inconsistent quality settings that make some variants appear softer or noisier than others. Server‑driven selection can misfire if Client Hints are not negotiated correctly, caching keys omit critical headers (Accept, DPR, Width), or CDNs normalise parameters improperly, causing cache misses or wrong responses. Finally, omitting intrinsic dimensions (width/height) prevents the browser from reserving space, increasing CLS regardless of variant quality.

Implementation notes

Prefer width‑based srcset for content images with a sizes attribute that mirrors your CSS breakpoints. A typical pattern provides 5–8 widths spanning common slots (e.g. 320, 480, 640, 800, 960, 1200, 1600, 2000), with formats offered via <picture> from most efficient to least (AVIF → WebP → JPEG/PNG). Use density‑based srcset only for images with constant CSS dimensions, such as logos or icons, and keep candidate densities aligned to device profiles (1x, 2x, optionally 3x). Always set width and height (or aspect‑ratio) on the element to stabilise layout and support responsive decoding.

Coordinate server and cache behaviour with selection inputs. If using Client Hints, opt in with Accept‑CH and vary caches on relevant headers (Accept, DPR, Width, Viewport‑Width) while considering privacy and support differences across browsers. When using query parameters (e.g. w=, q=, fmt=), ensure canonicalisation to avoid cache fragmentation and reflect only the variants you actively support. For LCP images, use rel=preload with imagesrcset/imagesizes to prime the correct candidate early; avoid preloading multiple variants. Test in realistic network conditions and inspect the chosen candidate via DevTools to confirm expected selection.

Comparisons

Width‑based srcset vs density‑based srcset

Width‑based srcset scales with layout and is the default for fluid content; it requires sizes but yields precise byte control across breakpoints. Density‑based srcset aligns to device DPR and is suitable for fixed‑size UI elements; it is simpler to author but risks oversupplying pixels when used for fluid images. Teams often use both: width‑based for photos and density‑based for logos and icons.

<picture> vs <img> with srcset only

<img> with srcset covers size and density. <picture> adds format switching and art direction via media conditions and multiple sources. Use <picture> when composition or codec must change per context; otherwise, <img srcset> is simpler and sufficient. Overusing <picture> with redundant sources increases markup and maintenance without performance gain.

Author‑defined variants vs server‑driven selection (Client Hints)

Author‑defined variants are explicit, deterministic, and work everywhere; they live in HTML and are cache‑friendly. Server‑driven selection tailors responses per request, shrinking markup and allowing finer granularity but requires careful cache keys and has uneven browser support for hints. Many stacks combine both: HTML provides width sets and format fallbacks; the CDN applies final codec/quality tuning per Accept and Save‑Data.

FAQs

Do I need both width and density descriptors in one srcset?

No. The HTML specification disallows mixing width (w) and density (x) descriptors within the same srcset. Choose width descriptors with sizes for fluid images, and density descriptors for fixed‑size UI images that do not change across breakpoints.

How many width variants should I generate?

Enough to keep byte deltas modest across breakpoints without creating maintenance overhead. Common practice is 5–8 widths covering typical slots from small mobile to large desktop, with closer spacing at smaller sizes where changes are more frequent. Avoid gaps that force large jumps (e.g. 480w directly to 1200w).

Should I always serve AVIF or WebP first?

Yes, when supported and visually acceptable. In <picture>, list AVIF first, then WebP, then JPEG/PNG as a final fallback, each with explicit type attributes. Always verify quality and banding on photographic and synthetic content, and provide a fallback for browsers lacking newer codecs.

Does using many variants hurt SEO through duplicate content?

Not when implemented correctly. Variants represent the same asset and are not indexed as separate canonical images if embedded through responsive markup. Keep a stable canonical URL for the image in sitemaps and structured data, and avoid exposing variant URLs as standalone navigable pages.

Why is my page still slow after adding srcset and sizes?

Likely causes include an inaccurate sizes attribute causing oversize downloads, missing modern formats, high quality settings, or lack of preload for the LCP image. Audit the chosen candidate in DevTools, confirm byte size and dimensions relative to the rendered slot, and verify that the hero image is preloaded with imagesrcset/imagesizes.