How many image variants should you prepare, and how should you manage them?
There is no fixed number of image variants that works for every page. Prepare a reasonable set of candidate images based on their display sizes on the page, users’ devices, and their intended uses, then assess the user experience. A full-width hero image may need more variants than a product listing thumbnail. The goal is not to cover every size and format, but to balance how well images fit their display requirements with cache efficiency, server costs, and HTML size.
Determine requirements by image use, rather than applying the same checklist to every image
web.dev notes that optimization results may differ between images, so the number of variants should not be determined solely by a site-wide specification. Even on the same e-commerce site, a full-width homepage hero image and product listing thumbnails may not need the same candidate sizes.
- Full-width hero images: Assess their size on the page and users’ devices; they may need more variants.
- Product listing thumbnails: Rather than simply reusing the hero image’s list of variants, choose variants based on the thumbnails’ own display requirements.
- Different images: Even when their uses are similar, assess the optimization results rather than assuming that adding variants will improve the experience.
More variants do not necessarily mean better overall performance
More candidate images may offer versions that better match users’ needs, but each additional variant comes with management and delivery costs. The source material notes that each variant requires its own cache entry. Compared with serving the same version to everyone, offering many variants may make cache use less efficient.
- Caching and origin fetches: If a variant’s cached copy has expired, the image needs to be fetched again from the origin server, which may reduce performance.
- Server costs: More variants may increase costs, so the suitability of an image in an individual transfer should not be the only consideration.
- HTML size: Listing each candidate size and format in HTML also adds markup.
This does not mean that keeping only one version is best. Rather, weigh these costs when adding candidates, instead of treating a comprehensive set of versions as an optimization success in itself.
Evaluate results through user experience, and use tools to help handle formats
To manage variants, start by organizing candidate images by use, then assess how those choices affect the user experience and adjust the number accordingly, rather than aiming for as many versions as possible from the outset. Consider both the image’s size on the page and users’ devices when evaluating results; do not simply apply one image’s results to other images.
An image CDN is one tool to consider: it can help optimize images and serve suitable formats based on users’ devices and browsers. However, format selection and the number of variants remain separate issues. Using a CDN does not replace assessing the number of candidates, caching costs, and the actual user experience.
Image variant counts and management: perspectives from across the web
What can you do if you do not want to list every image format in HTML?
The server can use the request’s Accept header to choose an image format supported by the browser, avoiding extra bytes in HTML for format candidates. For example, it can check for AVIF support first, then WebP, and otherwise serve JPEG. However, the source material cautions that Accept typically communicates supported image types only in requests for HTML resources, so implementations need to account for the information actually provided in the request.
What caching considerations apply when the same image URL returns different formats based on Accept?
Include Accept in the response’s Vary header so shared caches, such as CDNs, can distinguish between different responses for the same URL. This setting applies when the response is actually selected based on the value of Accept. Also bear in mind that, according to the source material, Accept typically communicates supported image types only in requests for HTML resources.
References
- Image performanceweb.dev — Discusses: What can you do if you do not want to list every image format in HTML?; What caching considerations apply when the same image URL returns different formats based on Accept?


Join the discussion 0 comments
What are you working through? Share a question or experience and let’s find the next step.
No comments yet. Start the conversation.