Responsive Images Performance

srcset, sizes, and density descriptors so browsers download the right image bytes for each viewport.

intermediate3 min readUpdated Aug 4, 2026

performance
responsive-images
srcset
sizes
lcp

Responsive images aren’t only art direction — they’re a performance feature. If sizes is wrong, the browser may download a 2000px file for a 360px slot and trash mobile LCP.

Docs: MDN responsive images, web.dev responsive images, Image formats.

Width descriptors (common)

<img
  src="/hero-800.jpg"
  srcset="/hero-400.jpg 400w, /hero-800.jpg 800w, /hero-1200.jpg 1200w, /hero-1600.jpg 1600w"
  sizes="(max-width: 600px) 100vw, (max-width: 1000px) 50vw, 600px"
  width="1200"
  height="630"
  alt=""
/>

Browser evaluates sizes → target CSS width.
Picks best w candidate for DPR and bandwidth heuristics.
Downloads that URL.

Wrong sizes is worse than no srcset. If you claim 100vw but display at 200px, you overfetch.

Density descriptors

<img src="icon.png" srcset="icon.png 1x, icon@2x.png 2x" alt="" width="32" height="32" />

Useful for fixed-size icons; width descriptors scale better for fluid layouts.

Art direction with picture

<picture>
  <source media="(max-width: 600px)" srcset="/hero-crop-m.avif" />
  <source srcset="/hero-wide.avif" />
  <img src="/hero-wide.jpg" width="1200" height="630" alt="" />
</picture>

Different crop on mobile can reduce bytes and improve composition.

LCP + responsive

Preload must match the resource that will actually be selected:

<link
  rel="preload"
  as="image"
  href="/hero-800.avif"
  imagesrcset="/hero-400.avif 400w, /hero-800.avif 800w"
  imagesizes="100vw"
  fetchpriority="high"
/>

Mismatched preload wastes bandwidth and can miss LCP.

Common bugs

Bug	Result
Missing `sizes` with `w` descriptors	Browser assumes `100vw`
Only 1x assets	Blurry on DPR 3 or huge files if only giant
Lazy LCP	Late discovery
No width/height	CLS

Interview out-loud

“srcset with w descriptors plus accurate sizes lets the browser pick bytes for the layout slot and DPR. I verify sizes against CSS, pair picture for art direction, and align preloads with imagesrcset for LCP.”

How this shows up in interviews

Be ready to define the metric or technique in one sentence, name one measurement approach (DevTools panel, web-vitals, or headers), and cite a concrete fix you would try first. Walk through a before/after: what the waterfall or flame chart showed, what you changed, and which percentile moved. Mention a tradeoff (complexity, caching correctness, or third-party business constraints) so the answer doesn’t sound like a blog checklist.

Production guardrails

Ship behind a flag when the change is risky, watch field p75 for the affected template for at least a few days, and keep a rollback path. Pair lab verification (throttled Performance/Network) with RUM so you don’t celebrate a Lighthouse-only win. Document the owner of any ongoing budget or third-party exception.

Further depth

Teams often under-invest in this topic until an incident or CWV regression. Schedule a one-hour drill: reproduce the failure mode in DevTools, list the top three mitigations for your stack, and file tickets with owners. Revisit after the next major feature that touches networking, rendering, auth, or third parties — those are the moments regressions land. Keep primary documentation links in the runbook so on-call is not searching chat history at 2am.

Concrete artifacts to leave behind: a short architecture note, a CI assertion or header snapshot, and a dashboard panel (lab or field) that would have caught the last bug. Teaching the rest of the team the mental model matters as much as the one-line fix.