Short answer: Start from measured layout widths, multiply them by the device-pixel ratios you intend to support, merge nearby results, and cap the set at the source’s useful size. A compact ladder usually serves users better than dozens of finely spaced variants.
An image API makes any width look cheap because a new derivative is one URL parameter away. At scale, arbitrary widths increase transformation work, storage, cache fragmentation, and operational noise. The browser also needs a truthful sizes value before its selection from srcset can be efficient.
What is a width ladder?
A width ladder is the approved set of derivative widths an application can request, such as 320, 480, 640, 800, 1024, 1280, and 1600 pixels. Each value becomes a candidate in a width-descriptor srcset. The browser combines those candidates with the declared slot size and device conditions to choose one resource.
MDN’s responsive images guide explains how width descriptors and sizes work together. The HTML standard leaves the final selection to the user agent, so your job is to provide useful choices and accurate layout information, not force an exact file.
The ladder should be shared policy. If every component invents widths, two visually identical cards may request different derivatives. Centralizing candidates makes the cache warmer and keeps the variant set inspectable.
How do you derive candidate widths?
Inventory the actual rendered slots in your design system. A card might be about 280 pixels in a narrow grid and 360 pixels in a wider one. An article image may range from 320 pixels on a phone to 760 pixels in the content column. A hero may reach 1440 pixels.
For each slot, calculate the physical pixel need at the device-pixel ratios you support. A 360 CSS-pixel card needs 720 source pixels at 2x. Do not blindly support every theoretical density. Above a point, extra bytes may produce little visible benefit, especially after compression and typical viewing distance.
Combine the resulting numbers, sort them, then merge close neighbors. A candidate at 780 and another at 800 rarely justify separate transforms. Round to stable values that your image service and component library can reuse.
Finally, cap candidates at the meaningful source width. Upscaling a 1000-pixel original to 1600 pixels does not create detail. Your URL builder should select the largest available candidate at or below the source constraint, or explicitly apply the platform’s no-upscale option.
How far apart should widths be?
There is no universal increment. Equal 100-pixel steps overproduce large variants and underserve the smallest range. Multiplicative spacing is a better starting point because the byte and perceptual differences scale with image area.
A ratio around 1.25 to 1.5 between adjacent values can produce a manageable initial set. Then validate it using real slots and content. Remove candidates that are almost never selected. Add one where field data shows browsers frequently choosing a much larger resource than required.
The goal is not mathematical elegance. It is to limit overfetch while keeping the cache and transformation surface bounded. The guide to preventing image variant explosion covers the operational side.
What should the markup look like?
Use width descriptors when the rendered size varies with layout. A simplified content image might offer 480w, 640w, 800w, and 1024w candidates, with sizes="(max-width: 700px) calc(100vw - 32px), 760px". That tells the browser that the image tracks the viewport on small screens and stops growing at the article column.
Generate every URL through the same transformation builder so crop, quality, format, and version remain consistent. Cloudinary provides responsive image concepts in its responsive images documentation, and the site’s responsive image API guide shows how browser markup fits the delivery contract.
Always include intrinsic width and height or an equivalent aspect ratio. Responsive selection saves bytes; intrinsic dimensions reserve layout space and reduce shifts. They solve different problems.
How do you validate the ladder?
Test representative pages at common breakpoints and a few intermediate widths. In browser developer tools, record the rendered CSS width, selected candidate, intrinsic width, transfer size, and device-pixel ratio. A selected resource modestly larger than the physical need is normal. A resource several times larger points to a bad sizes value or a missing candidate.
Repeat tests with a cold cache and network throttling. Confirm that the hero or likely LCP image is discoverable early. The web.dev guide to responsive image preloading explains how imagesrcset and imagesizes can be used when a responsive preload is genuinely necessary.
Review server logs after rollout. Aggregate requested widths by component or preset. Unexpected values reveal callers bypassing the ladder. Candidates with negligible traffic may be removable. High fallback use may reveal a gap.
A good width ladder is deliberately boring: a small shared list, grounded in the layout, enforced in code, and adjusted from evidence. That predictability is what lets an on-demand image API stay efficient.
Leave a Reply