Short answer: Most sizes problems come from describing the viewport instead of the image slot, ordering media conditions incorrectly, forgetting layout gaps, allowing markup to drift from CSS, or omitting sizes entirely. The browser then makes a reasonable choice from inaccurate information.
srcset provides candidate files. sizes tells the browser how wide the image will be before layout completes. The browser uses both pieces to start a request early. It cannot wait for every stylesheet and component to settle without delaying the image.
MDN’s responsive images guide is the best starting point for the syntax. The mistakes below are implementation problems that appear when the syntax no longer matches the design.
1. Declaring 100vw for a constrained image
sizes="100vw" says the image occupies the full viewport width. That can be close for a full-bleed mobile image, but it is wrong for a 760-pixel article column on a 1440-pixel display. The browser may choose a candidate nearly twice as wide as necessary.
Describe the slot. For a fluid content image with side padding and a desktop cap, use a value like (max-width: 792px) calc(100vw - 32px), 760px. Match those numbers to actual CSS tokens, not an illustration in a design file.
2. Writing media conditions in the wrong order
The browser uses the first matching condition. If a broad condition appears before a narrow one, the narrow rule never runs. This often happens when breakpoints are copied from mobile-first CSS into sizes without considering first-match evaluation.
Read the list from left to right at several viewport widths. For each one, identify the first true condition and calculate the resulting slot. Keep the final item as the default without a media condition.
3. Ignoring columns, gaps, and containers
A three-column card is not 33vw when the grid has a maximum width, side padding, and gaps. At some breakpoints the card may span two columns; at others it may become a list row with a fixed thumbnail. A rough fraction can be wrong in both directions.
Use calc() where the layout is predictably derived from the viewport. For complex component states, generate sizes alongside the component variant so the code understands whether it is in a one-, two-, or three-column layout. If the slot cannot be described, consider simplifying the design contract.
The site’s width ladder guide explains how candidate widths should be derived from these same slots. Candidates and sizes must be designed as one system.
4. Letting HTML drift from CSS
A developer changes the content maximum width from 720 to 800 pixels but forgets the sizes string. Nothing looks broken. Users simply download an unnecessarily large or slightly soft image.
Avoid duplicated magic numbers. Export shared breakpoint and container tokens to the image component where practical. Add visual fixtures for component variants and a browser test that compares rendered width with the selected image’s intrinsic width.
Do not make tests too strict. Candidate selection can vary between browsers and depends on density. Test a reasonable ratio, such as whether the selected intrinsic width stays within an agreed overhead above rendered width multiplied by DPR.
5. Omitting sizes with width descriptors
When a width-descriptor srcset has no useful sizes, the browser commonly behaves as if the slot is 100vw. That may be safe for visual quality, but it often wastes bytes for constrained content. The absence is especially costly on dense displays.
If the image truly spans the viewport, say so intentionally. Otherwise, add the real slot formula. For fixed-size icons or avatars, density descriptors such as 1x and 2x may express the problem more directly than a width ladder.
How do you find an incorrect sizes value?
Open the page in a clean browser session with the Network and Elements panels visible. Set a viewport and device-pixel ratio. Record the image’s rendered width, its currentSrc, the chosen resource’s intrinsic width, and transfer size. The HTMLImageElement.currentSrc property is documented by MDN.
Calculate rendered width multiplied by DPR. The selected candidate should usually be the first useful width at or above that requirement. If it is much larger, inspect sizes. If it is smaller and visibly soft, inspect missing candidates, source limits, and density assumptions.
Repeat at the precise breakpoint edges and just between them. A rule can be correct at 768 and 1024 pixels but wrong at 900. Also test the component in every context where it can appear; a reusable card may have different slots on search, home, and article pages.
Does sizes affect LCP?
Yes, when the LCP element is a responsive image. An exaggerated slot can cause a heavier file to be selected. An understated slot can yield a soft image and may trigger another fetch if scripts later alter the markup. The LCP image optimization guide covers discovery and priority in addition to sizing.
web.dev recommends that images generally include dimensions and appropriate responsive markup in its guidance on fast image loading. The important point is systemic: format, quality, preload, and CDN delivery cannot compensate for a browser being told the wrong display size.
Treat sizes as executable layout documentation. Review it when grids change, test it against rendered slots, and keep it close to the component that owns the CSS. That small discipline often saves more bytes than another round of encoder tuning.
Leave a Reply