A high-density screen can benefit from more source pixels, but doubling every image dimension quadruples its pixel count. The correct candidate depends on the rendered slot, device pixel ratio, image detail, compression, and whether the extra sharpness is visible at the intended distance.

The decision this guide supports

Provide enough pixels for important detail without forcing every visitor to download the largest source.

Repeatable method

1. Measure CSS slot widths

Record the component width at each layout state. A 360 CSS-pixel image may need a different candidate from a 760 CSS-pixel article image.

2. Calculate demand ranges

Multiply slot width by representative DPR values such as 1, 1.5, 2, and 3, then cap results at the source width. These are demand points, not mandatory exports.

3. Reduce the candidate set

Group nearby demand points into a maintainable ladder. Create files from the archival source, not by enlarging a smaller derivative.

4. Inspect perceived benefit

Compare one candidate step below and above the calculated demand. Fine line art may show a difference that a soft photograph does not.

Reproducible density-demand fixture

Use one 1800 × 1200 source and test at least two representative layout slots from your page. Treat the source dimensions and measured slot widths as controlled inputs, not quality results.

Candidate planning record

  • Measure the image slot in CSS pixels at every materially different layout state.
  • Multiply slot width by the tested device-pixel ratio, then cap demand at the source width.
  • Record the nearest available candidate, its bytes, currentSrc, and naturalWidth.
  • Inspect the result at the intended display size; do not infer visible benefit from DPR alone.
  • Decision rule: add a larger candidate only when the visible improvement justifies its transfer and maintenance cost.

Export every candidate from the same master with one encoder and one documented quality setting. Place the image in a fixed-width test component, switch device pixel ratio in browser emulation, disable cache, and inspect currentSrc. Compare fine edges at normal viewing size, not only at zoom. Record when the next candidate changes visible detail enough to justify its additional bytes. Repeat with a soft photograph and line artwork because their useful density thresholds may differ.

What to record

Record CSS slot width, DPR, candidate intrinsic width, source width, bytes, compression setting, viewing distance, and whether a reviewer could identify the sharper candidate without labels.

Do not turn a lab result into a universal rule

A result belongs to the source file, encoder, settings, browser, viewport, cache state, and date that produced it. Repeat the test on representative files before changing a production workflow.

Common mistakes

  • Treating every DPR 2 device as requiring exactly 2× pixels
  • Upscaling a derivative and calling it high resolution
  • Ignoring that pixel count grows with both width and height
  • Sending a 3× hero when the visible difference is negligible

Verification checklist

Use responsive mode and at least one physical high-DPI device. Inspect currentSrc, transferred bytes, sharp edges, fine text inside the image, and the result under a slow-network profile.

Primary references

Related lab notes

About this guide

We distinguish documented platform behavior from our workflow recommendations. See the testing methodology, editorial policy, and corrections log.