A responsive layout can look correct while sending unnecessarily large images to visitors. Shrinking an image with CSS changes its displayed dimensions, but a useful image strategy also considers which file the browser downloads.
HTML provides tools for describing alternative image resources and their intended display conditions. Using those tools accurately helps connect the visual design to the resources delivered over the network.
Describe candidates and layout separately
The srcset attribute can list alternative image files with width descriptors. The sizes attribute tells the browser how much layout space the image is expected to occupy under different conditions.
For example, an image in a desktop card grid may occupy only one-third of the viewport, while the same card becomes almost full width on a narrow screen. The largest viewport does not automatically require the largest image candidate.
Google’s web.dev guidance explains that sizes should describe the image’s expected rendered width, giving the browser information it can use when selecting a resource.
Begin with the actual component layout. Measure the content width and the gaps around it before writing the markup.
Distinguish resizing from art direction
Sometimes the same composition works at every size. In other cases, a wide photograph becomes unhelpful when squeezed into a narrow card because the subject becomes too small.
The <picture> element allows different image sources to be offered according to conditions such as media queries or supported formats. It still contains an <img> element that supplies the fallback and alternative text.
This gives designers a way to choose a different crop when the composition needs to change, rather than merely offering the same image at several resolutions.
A practical example is a wide product photograph with the object at one edge. A tighter mobile crop may communicate the subject more clearly than a smaller version of the entire desktop composition.
Reserve space and prioritize deliberately
Include appropriate width and height attributes so the browser can establish an aspect ratio before the image finishes loading. This helps prevent surrounding content from moving unexpectedly.
Loading behavior also deserves attention. web.dev recommends lazy loading for images farther down a page and avoiding it for an important hero image visible immediately. High fetch priority should be reserved for genuinely important images rather than applied throughout a gallery.
These controls work best when used selectively. Giving every resource special priority removes much of the value of prioritization.
Test what the browser actually requests
Review the final page at several representative widths. Inspect the selected image resource and compare its dimensions with the rendered component.
Repeat the check with an empty cache when investigating downloads. Otherwise, a previously cached image can make the result difficult to interpret. Also inspect the page while images are loading, not only after everything has settled.
For a publishing workflow, make this a component-level review. Check the hero, article body image, thumbnail grid, and related-content card independently because their layouts differ.
Keep image choices tied to those components as the design evolves. When a card moves from three columns to two, revisit its sizing information. Responsive images remain effective when the markup continues to describe the design that users actually receive.
