How would you use srcset and sizes for responsive image performance?
This tests responsive image selection in the browser. A strong answer covers srcset with w or x descriptors, sizes for layout width hints, and the browser picking before CSS loads. Red flag: suggesting JS detection or CSS backgrounds instead.
What's really being asked
This question evaluates whether you understand the browser's native responsive image pipeline, specifically how to decouple image resolution from display size to save bandwidth and improve Core Web Vitals. The interviewer wants to know if you can explain the difference between art direction, which uses the picture element, and resolution switching, which uses srcset and sizes. They also care whether you recognize that the browser makes its download decision early in the page lifecycle, before it knows the final rendered size from CSS, so developer hints are critical.
The full answer
First, explain that srcset provides a comma-separated list of image URLs with either width descriptors like 480w and 800w, or density descriptors like 1x and 2x. Second, clarify that width descriptors require the sizes attribute, which tells the browser the intended display width of the image in different layout conditions using media-query-like syntax such as max-width. Third, describe how the browser uses its viewport width, device pixel ratio, and the sizes hint to pick the smallest adequate source from srcset before downloading. Fourth, mention that if neither srcset nor sizes is supported, the img element falls back to the standard src attribute. Fifth, note that intrinsic width and height attributes should still be included to prevent layout shift.
The mistakes people make
A major red flag is suggesting JavaScript to detect screen density and swap the src after page load, because that forces a double download and blocks rendering. Another mistake is confusing srcset with the picture element; picture is for art direction where cropping or format switching matters, while srcset is for resolution switching within one aspect ratio. Candidates also err by omitting sizes when using w descriptors, which causes the browser to assume the image fills the full viewport width and may select an unnecessarily large file. Finally, proposing CSS background images with image-set as the primary strategy misses the point for content images that need alt text and semantic HTML, and relying on server-side user-agent sniffing is brittle and unreliable.
What usually comes next
The interviewer may ask when to use the picture element instead of srcset, how to handle lazy loading with responsive images, or how to prevent cumulative layout shift when the final image dimensions are unknown. They might also probe how a content delivery network can automate srcset generation, or ask about modern formats like AVIF and WebP alongside fallback sources. A sharp candidate should also be ready to discuss how preload links interact with responsive images and why preloading the wrong density can waste bandwidth.
A concrete example
Imagine a hero image that occupies 100 percent of the viewport width on mobile but only 33 percent on desktop. You would provide three source files at 400w, 800w, and 1600w in srcset. The sizes attribute would read max-width 600px 100vw, 33vw. On a 320px wide phone with a 2x DPR, the browser calculates it needs roughly 640 pixels of width, so it selects the 800w source. On a 1200px desktop with 1x DPR inside a 33vw slot, it needs about 400 pixels, so it selects the 400w source, avoiding a 1600w download and improving LCP.
Interview question
If you provide srcset with w descriptors but omit the sizes attribute, how will the browser behave?
- a.It waits for CSS to resolve the image's final rendered width before downloading
- b.It always picks the smallest listed source to minimize data usage
- c.It assumes the image fills the viewport width and may select an unnecessarily large fileCorrect
- d.It falls back to the src attribute because srcset is invalid without sizes
Why? this is the answer
Without sizes, the browser defaults to assuming the image spans the full viewport width, which can lead it to download an unnecessarily large file. It makes this choice before CSS loads, so it cannot wait for the final rendered width.
Just read this? Test yourself on what you have been reading.
Read the original → developer.mozilla.org
- #html
- #responsive-images
- #performance
- #srcset
- #frontend
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on html — each one lists the topics its interview covers.
See open roles