You are setting up a pipeline that generates several widths of every photo on a site. How do you decide which widths to generate, and where does the ladder stop at the top?

## Start from the image's layout width, not the viewport The single most common error in building a responsive image ladder is to reuse the site's CSS breakpoints as image widths. Those numbers describe the *viewport*, and an image almost never occupies the whole viewport. A product card image inside a four-column grid on a 1440px desktop layout might be laid out 320px wide; generating a 1440px variant for it produces an asset no device will ever legitimately select, while the widths that actually matter cluster below 700px and may not exist at all. So the ladder is derived per *image role*, from that role's real layout width. Walk the breakpoints and write down what the CSS actually gives the image at each: hero 100% of viewport up to a 1280px container; card image one quarter of a 1200px grid minus gutters, so about 280px; avatar a fixed 48px. Those are three different ladders, and they should be, because they are three different byte problems. ## The top of the ladder The largest width worth generating is the widest CSS width the image is ever laid out at, multiplied by the highest device pixel density you commit to serving. For a hero capped at a 1280px container with a 2x commitment, that is 2560px, and generating a 3200px variant is pure storage cost — no selection algorithm will pick it, because no layout can use it. For the 280px card image, the top of the ladder is 560px, and the fact that phones exist with 1400 physical pixels of width is irrelevant: the *element* is 280 CSS px wide there too, or narrower. There is a second reason to cap deliberately. Source photos are frequently 4000–6000px straight out of a camera or a stock library. If the pipeline is "generate every width up to the original," you inherit gigantic assets that only exist because of the source, not because of the design. Anchor the ceiling in layout, not in the source. ## Spacing the steps Once the ceiling is set, the remaining question is how many steps and where. Even spacing is the intuitive choice and the wrong one. Consider 400, 800, 1200, 1600, 2000: the first step is a 100% jump in width and roughly a quadrupling in bytes, so a device needing 500px is forced up to 800 and over-downloads badly; meanwhile 1600 and 2000 are visually and byte-wise close neighbours, so the expensive end of the ladder carries near-duplicates. Geometric spacing fixes both ends. Pick a growth factor — 1.25 to 1.4 is the usual range — and generate 400, 520, 680, 880, 1140, 1440. Now every device over-downloads by at most the growth factor's worth of width regardless of where it lands, which is the property you actually want: bounded relative waste. A refinement some pipelines use is to space by *bytes* rather than by width: encode the image, then choose widths so each variant is roughly a fixed number of kilobytes larger than the previous one (say 20 KB). This adapts automatically to content — a flat gradient compresses so well that widely separated widths barely differ in size, while a detailed photo needs more rungs. It is more machinery than most teams need, but it is the principled version of the same idea. ```javascript // Geometric ladder: bounded relative over-download at every rung. const ladder = (min, max, factor = 1.3) => { const widths = []; for (let w = min; w < max; w = Math.round(w * factor)) widths.push(w); widths.push(max); return widths; }; // ladder(400, 1440) -> [400, 520, 676, 879, 1143, 1440] ``` ## How many rungs Five or six per role covers the realistic device space with bounded waste. Beyond that the marginal saving per added rung shrinks fast — the difference between a 4-rung and an 8-rung ladder is typically a few kilobytes per request — while build time, storage, and cache fragmentation all grow linearly. Below three rungs you are back to forcing large groups of devices onto a badly-fitting asset. ## Keep ladders shared, not per-image Define ladders per role and reuse them across every image in that role. Two benefits follow. First, the numbers stay reviewable: a handful of named ladders is something a team can reason about, where per-image ladders are not. Second, shared widths mean shared URL shapes and a smaller, hotter set of distinct assets at the edge, which matters more than the last few kilobytes of fit. Round the generated widths to tidy values for the same reason — a ladder of 400/520/680 across the whole site behaves better in caches than one image at 517 and another at 523. ## Sanity-check against reality After the ladder ships, verify it empirically: on real pages at real viewport sizes, check which rung devices actually land on. If everything is choosing the top rung, your ceiling is set below what the layout needs. If a rung is never chosen by anything, delete it — it is pure cost.