Responsive Images and WebP: Keep srcset Honest

Converting a large JPEG to WebP can reduce file size, but it does not fix a dishonest srcset. If the browser is still asked to download a 2400-pixel image for a 420-pixel card, the page is carrying avoidable weight. Format choice and responsive image delivery need to work together.

The purpose of srcset is to give the browser honest options. The browser can then choose an image based on viewport width, device pixel ratio, layout, and network conditions. WebP can make those options lighter, but only if the generated variants match the layout the page actually uses.

Copying a srcset snippet is not the same as optimizing responsive images. A useful implementation proves that the candidate widths exist, that each descriptor matches the real file, that fallback formats are aligned, and that the browser actually downloads the expected asset at real breakpoints.

Audit the Display Sizes First#

Before generating WebP variants, inspect the real rendered image sizes. Do this at the breakpoints your site supports: mobile, tablet, laptop, and wide desktop. Record the largest displayed width for each image role.

For example:

• blog card thumbnail: 360px to 520px
• article hero: 720px to 1280px
• product detail image: 600px to 1000px
• gallery zoom image: 1400px to 2000px

These numbers should drive your output widths. Do not generate sizes just because another site uses them or because a build plugin ships with defaults.

Generate Variants From the Same Source#

Responsive image sets should be created from the same approved source image. Mixing files from different exports can create visible jumps when the browser switches candidates. This is especially noticeable for product photos, portraits, gradients, and screenshots.

A clean workflow looks like this:

source: hero-original.jpg
outputs:
  hero-640.webp
  hero-960.webp
  hero-1280.webp
  hero-1600.webp

Keep the source available so the set can be regenerated when layout changes. Do not repeatedly resize from an already compressed output.

GetWebP should sit after the resize step in this workflow. Use your CMS, image pipeline, or design export process to create the actual width variants, then convert those prepared variants to WebP:

mkdir -p ./reports

getwebp ./responsive-working \
  --recursive \
  --output ./public/images \
  --json \
  --manifest ./reports/responsive-webp-manifest.json \
  > ./reports/responsive-webp.ndjson

If you use one shared output directory, keep variant basenames unique. getwebp ./responsive-working --output ./public/images writes outputs by basename into the selected output directory; it does not mirror nested source folders. A duplicate such as cards/hero-960.jpg and articles/hero-960.png can compete for the same hero-960.webp output unless you rename or split the output path.

Use the NDJSON report for conversion status and the manifest for successful output fingerprints:

jq -r '
  select(.type == "convert.completed")
  | .data.results[]
  | [.status, .file, .outputPath, .originalSize, .newSize, .savedRatio]
  | @tsv
' ./reports/responsive-webp.ndjson

The GetWebP CLI command reference documents the conversion flags, and the JSON output guide explains the report fields.

Write srcset Widths That Match the Files#

Each width descriptor must describe the actual file width:

<img
  src="/images/hero-1280.webp"
  srcset="/images/hero-640.webp 640w, /images/hero-960.webp 960w, /images/hero-1280.webp 1280w"
  sizes="(max-width: 768px) 100vw, 1280px"
  width="1280"
  height="720"
  alt="Workspace with a laptop showing a design review"
/>

Do not label a 900-pixel file as 1280w to make markup look consistent. Browsers use those descriptors to make loading decisions. Incorrect descriptors can cause blurry images or wasteful downloads.

MDN's responsive images guide explains how srcset and sizes affect browser selection. The HTML image element reference is useful when checking attributes such as alt, width, height, and loading.

Keep WebP and Fallback Sets Aligned#

If you serve WebP through a picture element, the WebP and fallback formats should represent the same image dimensions:

<picture>
  <source
    type="image/webp"
    srcset="/images/card-480.webp 480w, /images/card-960.webp 960w"
    sizes="(max-width: 700px) 90vw, 480px"
  />
  <img
    src="/images/card-480.jpg"
    srcset="/images/card-480.jpg 480w, /images/card-960.jpg 960w"
    sizes="(max-width: 700px) 90vw, 480px"
    width="480"
    height="320"
    alt="Handmade ceramic bowl in matte blue glaze"
  />
</picture>

If the fallback set has different widths, your performance test may compare different images rather than different formats.

Review Cropping and Art Direction Separately#

Sometimes responsive images need different crops, not just different sizes. A wide desktop hero may not work on a narrow phone screen. In that case, use picture for art direction intentionally and document the crop choices.

Do not hide cropping mistakes behind WebP conversion. A smaller file is still a poor user experience if the subject is cut off on mobile or if text inside an image becomes unreadable.

Check the Network Panel#

After implementation, open the page at several viewport widths and inspect which file downloads. Confirm that:

• the selected file width makes sense for the rendered size
• the WebP file is served with the expected content type
• fallback files still exist
• lazy-loaded images do not load too early
• above-the-fold images are not delayed unnecessarily

For each template, test one real page rather than trusting generated markup alone.

Record the browser check in a small table so it can survive a later redesign:

template,viewport,dpr,rendered_width,downloaded_file,result
article,390px,3,390px,hero-1280.webp,ok
article,768px,2,720px,hero-1600.webp,ok
card-grid,1440px,1,420px,card-480.webp,ok

If the browser downloads a much larger candidate than the rendered size and DPR justify, inspect the sizes attribute before changing compression settings.

Recheck After Design Changes#

Responsive image rules age as layouts change. A card that was 360 pixels wide last quarter may become 520 pixels wide after a redesign. A hero that used to be constrained may become full-bleed on large screens. When that happens, old srcset widths can become either too small or unnecessarily large.

Add image variant review to layout changes, not only compression projects. If a component changes width, the image candidates and sizes attribute should be reviewed with it.

Good responsive image delivery is honest bookkeeping. WebP reduces the weight of each candidate, while srcset and sizes help the browser choose the right candidate. When those pieces agree with the actual layout, image optimization becomes measurable instead of hopeful.