A photo card might be 360 pixels wide on a phone and 600 on desktop. Serving a single 2400-pixel file is simple but can transfer more data than a small screen needs. Start by measuring the actual space. Then produce a few candidates that cover the space and different screen densities.

Measure the layout’s limits

The phone’s width and the image slot may differ. Margins, columns, and the page’s maximum width affect the slot. Measure it at the narrow and wide ends. If a card is shown at 360 and 600 CSS pixels, files that are 360, 720, and 1200 pixels wide make a reasonable first trial.

Export candidates from the same crop

For resolution switching, match the framing and aspect ratio so a different file does not change the composition. In HTML, the widths in srcset describe the files’ real pixel widths, while sizes describes the space in the layout. The browser uses those hints to choose a suitable candidate for the device and conditions. MDN responsive images guide

Handle a change of crop separately

If a wide header loses its subject on a phone, making the same crop smaller will not fix it. Make a separate mobile crop from the scene and select it for that layout. The text that describes the image should still make sense with both crops.

Check the request and the result

Open the page fresh in a narrow window. Check the requested file name and transferred size in the network panel. Repeat at a wider width and higher density. A browser may reuse a larger candidate already in cache. Look at the subject, sharpness, and reserved space in both layouts.

Measure a card and a full-width cover separately

Imagine using the same mountain photo as a homepage cover and as a card in a three-column grid. The card might be 360 pixels wide and the cover 1,200. Serving the largest export to both is simple, but the card would make visitors download detail they cannot see. Open the layout in a narrow and a wide browser window. Measure the space the image actually takes up. When the number of columns changes, a card may get narrower even as the window grows. Leave a larger candidate for screens with higher pixel density. Measure the picture slot itself, since the heading and the text beside it can occupy different widths. If the same card appears elsewhere on the site, check that placement too. A cover that cuts off its subject in a card may require a different crop. That is a separate decision from preparing multiple widths of the same composition. Keep names descriptive enough to tell a crop from a resize.

Inspect the file the browser chooses

Open the browser's network tools, temporarily disable caching, and reload the page in a narrow window. Locate the image request, note which width the filename represents, and record the bytes transferred. Repeat the test in a wide window. Seeing the same file twice does not establish a problem on its own. Pixel density and a previously loaded resource can affect the choice. If the browser picks a candidate far larger than it needs, revisit the sizes that describe the layout. The markup might be describing a grid card as if it occupied the full window. If the text moves when the picture appears, reserve space using the image's aspect ratio. Finally, try a slower connection and see when the first visible cover appears. A change that removes unnecessary downloads and keeps the headline in place solves two practical problems. Retest one below-the-fold image so the cover optimisation does not inadvertently make the browser load the whole gallery at once.