Why Does My Browser Download a Product Image Much Larger Than Its Displayed Card?

Understand the two width declarations

With width-descriptor responsive images, srcset lists candidate resources and their intrinsic widths, such as 400w, 800w and 1600w. The sizes attribute tells the browser the intended display width under the relevant conditions.

MDN explains that the browser combines these hints with device pixel density to select a resource. The CSS layout determines the eventual rendered width, but that layout and the declared sizes hint can disagree.

For example, a card may occupy 320 CSS pixels while sizes declares 100vw on a 1200-CSS-pixel viewport. The browser can consequently evaluate candidates against a much larger assumed slot than the card actually uses.

Do not treat this as a defect in the photograph's generation. The image may be perfectly valid while the HTML provides an inaccurate loading hint.

Compare the selected file with the actual slot

Inspect one product card at a defined viewport, browser zoom and device pixel ratio. Record the image's rendered CSS width, its sizes attribute and its complete srcset candidate list.

Use the image element's currentSrc property and the Network panel to identify the selected resource. Confirm its actual pixel dimensions; a filename containing '1600' is not sufficient evidence.

A useful first estimate is rendered CSS width multiplied by device pixel ratio. This is a diagnostic comparison, not a requirement that browsers always select exactly that width. Browsers can consider bandwidth, available candidates, caching and other implementation choices.

Check that every width descriptor accurately represents its file's intrinsic width. Incorrect descriptors can make an otherwise sensible sizes declaration misleading.

If the selected resource is oversized relative to the declared slot, inspect the candidate ladder. If sizes itself is much wider than the rendered card, repair that mismatch first.

Correct the hint without weakening the product image

Ask the theme developer to make sizes reflect the actual responsive card layout. A grid that changes from one column on phones to four columns on desktop may need more than one condition.

Do not simply delete the largest candidate. The same image may also serve a wider detail page or an enlarged gallery view. Those placements can require different markup or rendition choices.

Compare the revised page under the same viewport and cache conditions. Record selected URL, transferred bytes and whether the buyer-critical label remains readable. A smaller transfer is useful only if the product remains clear at the intended viewing size.

Keep responsive source selection separate from art direction. If the browser selects the wrong composition, inspect picture source conditions; if the right image is merely oversized, investigate sizes and candidate widths.

Hypothetical case: a narrow product card

Hypothetical browser fixture; no page was measured. A fictional product card renders at 320 CSS pixels on a viewport 1200 CSS pixels wide, with device pixel ratio 2. Its approximate pixel budget is 640 pixels.

Candidate A declares sizes="100vw" and offers 400w, 800w and 1600w resources. That hint describes a 1200-pixel slot and can lead to an unnecessarily large selection.

Candidate B declares a 320-pixel slot for this layout while retaining the same candidates. An 800-pixel resource is a plausible candidate for the approximate 640-pixel budget, although the browser's actual choice must be observed.

Approve B only after verifying its real selected resource and label detail.

Record your own observations

The filled rows are illustrative examples. Use the blank row for your own files and observations.

Download the editable CSV worksheet

What the references establish

• MDN — Responsive Images: Documents srcset width descriptors, sizes conditions and browser candidate selection.
• MDN — img HTML Element: Documents intrinsic-width descriptor requirements and how sizes participates in image selection.