Responsive image sets

Where the numbers come from

A candidate file is only useful if some real device will choose it. Which files a device chooses is decided by two things you control — the rendered width of the picture at that viewport, and what you told the browser that width would be — and one you do not, the screen’s pixel density. So the list is built from the layout outwards, in four steps:

• Write down every breakpoint at which the picture’s box changes size.
• At each one, work out the widest the box can be, in CSS pixels.
• Double each of those for the dense screens you intend to serve properly.
• Sort, round, and throw away anything that sits within a quarter of its neighbour.

Step two is the one people skip, and it is arithmetic rather than judgement. Take a grid: a container that stops growing at 1200 pixels with 24-pixel gutters, three columns above 1024, two above 640, one below it. The picture is never wider than its column, so:

That yields eight candidates: 368, 476, 592, 736, 952, 1184 and their duplicates. Round them outward to the nearest sensible number, drop the pairs that are close together, and the list is 400, 600, 800, 1200. Four files, and every one of them is the file some real device will ask for. Notice what is not in the list: 1920, which nothing in this layout can ever use.

The widest box is not the viewport

The single most common mistake is building the list from screen sizes — 1920, 2560, because monitors are that wide. A picture in a three-column grid on a 2560 monitor is still 368 CSS pixels across. Serving it a 1920-wide file is not generosity, it is a megabyte spent on a picture that will be drawn at a seventh of its size, and the browser only avoids doing that if the list gives it something better to pick.

How far apart is far enough

Bytes go up roughly with area, so a file 40% wider than its neighbour is about twice the size. That is the frame for the spacing question: a gap is too wide when a device landing in the middle of it is made to download something noticeably larger than it needs, and too narrow when you are writing files that differ by a few kilobytes.

Four to six widths covers almost every layout. Past that you are adding files to the archive and rows to the plan for a difference that the encoder’s quality setting is already larger than.

When a second pixel ratio earns its bytes

A ×2 file is four times the pixels of its ×1, and it buys a visible difference in exactly one situation: hard edges viewed closely. A photograph of a landscape at ×1 on a dense phone screen looks soft to someone looking for softness. A product shot with a printed label on it, a screenshot, a diagram or anything containing type looks wrong immediately.

• Photographs, large on the page: ×1 and ×2, and let the quality setting fall a little on the ×2.
• Small tiles under about 400 pixels: ×1 and ×2, because both files are cheap anyway.
• Screenshots, diagrams and anything with lettering in it: ×2 is not optional.
• ×3: only for marks and avatars, where the file is a few kilobytes and the edges are geometric.

There is no separate mechanism for this. A ratio variant is just another width, and once the set has been expanded the ×2 of a 600 and a plain 1200 are the same file asked for twice — which is why deduplicating the sorted list at the end of step four matters more than it looks.

Writing sizes so the list gets used

The width list is the menu; sizes is the order. Get it wrong and the browser picks from the menu correctly against a number that was never true, which looks exactly like the list being wrong.

sizes="(min-width: 1024px) 368px,
       (min-width: 640px) calc((100vw - 72px) / 2),
       calc(100vw - 32px)"

Three things about that attribute are worth knowing, and all three catch people out:

• It is read before layout happens. The browser has to start the download before it knows where the picture will sit, so it believes the attribute rather than the page. A stale sizes after a redesign is a silent regression.
• The conditions are tried in order and the first match wins, so the widest breakpoint goes first and the last entry carries no condition at all. Reversing that makes every device take the mobile branch.
• The units are the box’s, not the file’s. 100vw on a picture that is half the screen wide asks for roughly twice the file it needs, on every device, forever.

The descriptors on the other side — the 320w after each filename — are the real pixel widths of the files on disk, which is why they are worth generating rather than typing. A descriptor that lies by 40 pixels is a picture chosen from the wrong rung of the ladder.

Art direction is a different problem

Everything above is resolution switching: the same picture, more or fewer pixels. If what you want on a phone is a different crop — the subject, close, instead of the wide shot — no width list will do it, because the browser is choosing between files it believes are interchangeable. That needs <picture> with real <source> elements and a separately cropped file, and it is a decision per image rather than a rule over a folder.

Generating the set

Once the list exists, producing the files is mechanical, which is the part this site does. The responsive control takes the widths and the ratios, expands them into ordinary rules, drops any width larger than the source rather than inventing pixels, and prints the markup beside the plan so the two lists cannot drift apart.

The control is on its own page with the set already switched on, and what the files end up called is on the naming reference. The other two guides are back on the guides index.