Set up a responsive image pack for an agency build

Pick widths from real breakpoints, not guesswork

A responsive image pack is only useful if the widths match what the layout actually displays. Start from your CSS breakpoints and the content widths your templates use. A common agency set covers:

• a narrow mobile width (around 480 to 640),
• the mid tablet width (around 960),
• and a desktop width (1280 to 1920 for hero imagery).

You do not need a variant for every device. You need a variant for every content width the design uses. A hero that spans the full viewport at 1280 wide does not benefit from a 400 width variant, because the browser would never choose it.

Generate the variant set in one pass

From a source image, the responsive pack produces each requested width as a separate file, all named consistently and emitted as a group. That is the difference between this and one-off resizing: the whole set is produced together, so a single image becomes a coherent family rather than a set of ad hoc exports.

The responsive image pack page shows the preset groups, including a standard set at 320, 640, 960, 1280 and 1920, which fits most agency migrations. A small site can use a lighter trio; a hero-heavy landing site wants the large set.

Emit srcset and sizes

Once the variants exist, the markup needs two attributes so the browser picks well:

• srcset lists each width variant with its width descriptor (320w, 960w, and so on).
• sizes tells the browser how wide the image will render at each breakpoint (100vw for a hero, 33vw for a three-column card).

The browser then downloads the smallest variant that fits the current screen and pixel density. Get sizes wrong (50vw when the layout is actually 100vw) and the browser fetches a smaller-than-needed file, which blurs on high-density screens.

Hand the manifest to the build

The useful output for an agency is a mapping the build can consume: for each source, the list of generated variants, widths and filenames. A static site generator or a small script uses it to write the final markup without manual HTML edits. This is the migration manifest handoff pattern, and it is the reason the pack earns its keep across many client projects: once the pipeline exists, a new site is configuration, not rework.

Verify the result by loading a page at a few viewport widths in DevTools and confirming the network tab fetches one appropriate variant per image rather than one giant file.