How to prepare responsive images for a business website

Prepare website images around their actual job: choose a clear subject, review the crop at the sizes where it will appear, export appropriate variants and check which file the browser requests. A smaller file is useful only if the image still communicates what the page needs.

Decide what each image contributes

Start with a short image list for the page. Record the section, the question the image answers, the approved source and who can replace it later. A project screenshot may demonstrate a real interface; a photograph may establish context; a diagram may explain a relationship. Those roles need different review criteria.

Keep important headings, prices and instructions as live page content. A photograph of a worksheet can preview the resource, but readers still need its usable text or download. An image that looks attractive in a folder can become unhelpful when its subject is cropped out on a phone.

For the wider page plan, use the website brief template. It gives the image decisions a real audience and purpose.

Match the crop to the component

Review the actual article cover, card, mobile screen and social preview separately. A 3:2 article image and a wide social card have different boundaries. Preserve the subject in each export instead of assuming one automatic center crop will work everywhere.

For a product interface, check whether the part that matters remains legible. If a full dashboard becomes a collection of tiny labels, use a focused capture and explain its context in nearby text. Do not fabricate a more convenient interface and present it as a screenshot of the product.

Our editorial workflow uses 3:2 reading images and 1200×630 social crops. Those are this site's component choices, not universal requirements for business websites. Choose dimensions from the layout you are actually delivering.

Export a small set of useful sizes

Identify the largest display slot, common narrower slots and the detail the image needs to retain. Then export a limited set of widths that covers those uses. Do not publish a large original simply because it was the file supplied by a camera or design tool.

For photographic editorial covers on this site, we currently use 480, 960 and 1536 pixel widths. We inspect the optimized output for texture, faces and obvious artifacts. For screenshots, we pay particular attention to small text and hard interface edges. A file format or quality setting is a decision to review, not a badge that proves optimization.

Keep an approved editable original when future production needs it. Where a compressed image is deliberately the final editorial master, record that decision and keep its provenance. Remove redundant conversion copies after verification; do not delete unique client source material in a general cleanup.

Tell the browser about the available files

HTML can offer multiple image candidates through srcset. A sizes value describes the expected display slot; it must reflect the actual responsive layout. The browser combines that information with factors such as display density when choosing a candidate. The web.dev responsive images guide explains this mechanism.

For example, a reading image that is roughly the phone's content width on mobile and limited by a desktop reading column needs sizing information about that column. Describing every slot as the full viewport can encourage unnecessarily large downloads in a desktop card grid.

Ask the developer to show the image element, the rendered width and its currentSrc in a fresh browser context. Resizing a tab that already downloaded a large image is an incomplete test of a new visitor's request. A high-density phone may correctly select a larger source than a standard-density screen of the same CSS width.

A measured example from this website

The published WordPress-building photograph has three reading variants. On 29 October 2026, the exported files were:

• 480×320: 18,272 bytes.
• 960×640: 41,784 bytes.
• 1536×1024: 116,396 bytes.

You can inspect the actual 480px file, 960px file and 1536px file. These are measured output sizes for one image, not a compression forecast for a different photograph or screenshot. They do not include other page requests or establish a loading-time improvement.

The useful review is whether the browser chooses an appropriate candidate and whether the visible result remains clear. A small image that is stretched beyond its useful detail and a needlessly large image can both fail that review for different reasons.

Reserve space and choose loading behavior

Provide image dimensions so the layout can reserve the right proportions before the file arrives. Check the component itself as well: a conflicting fixed height or an unexpected crop can still produce a poor result.

Use loading behavior according to placement. Important images visible when the page opens should be allowed to load normally; images farther down can often be lazy-loaded. The web.dev lazy-loading guidance explains why delaying a critical opening image can hurt the experience. Adding every image to a preload list is not a substitute for deciding which resource matters first.

Evaluate the first screen at the actual mobile and desktop sizes. A cover below a long article introduction may be offscreen on one viewport and near the opening screen on another. Record the decision with the component rather than copying an attribute blindly across the website.

Write alternatives and captions for the context

Describe the information the image contributes to that page. Decorative images can have an empty alternative; an image acting as a control needs an alternative that communicates its action. The W3C alternative-text decision tree helps distinguish these cases.

Use captions to make provenance clear where it matters. Identify generated editorial photographs honestly, date a product capture and attribute approved project work. Do not describe fictional people as a real client team or imply that a screenshot proves a business result.

Review before calling the images ready

Check a narrow phone, a larger reading layout and a high-density display. Confirm that the subject survives each crop, the image loads from a public URL, dimensions match the export, and the requested candidate makes sense. Review the social preview separately from the page cover.

Save a small evidence record with the page URL, viewport, display density, requested source, output size and any unresolved crop issue. This is more useful for the next editor than a folder full of unlabeled exports. Include image loading in the website launch checklist.

Primary documentation and the published example files were checked on 29 October 2026. The cover is an AI-generated editorial photograph. The measured file sizes are asset evidence; they are not field Core Web Vitals, conversion or ranking measurements.

The Blitz Studio team

We design brands, build websites and engineer digital products.

Talk about your next project