Support limits of next/image responsive srcset when sizes is omitted

Answer first

The waste you see with next/image when sizes is omitted is normally a layout-hint problem, not an optimizer limit. Next.js still emits a srcset built from images.deviceSizes and images.imageSizes. With no sizes attribute the browser falls back to 100vw, so it picks the smallest candidate that satisfies 100vw × device-pixel-ratio. That candidate is often wider than the actual rendered slot.

Adjust the layout hint first. Only change deviceSizes or imageSizes if you need a global reduction in candidate count and you accept a cache bust.

Confirmed facts

• Next.js generates srcset from the deviceSizes and imageSizes arrays in next.config.js regardless of whether sizes is provided.
• When sizes is missing, browsers use a default layout hint of 100vw.
• Changing deviceSizes or imageSizes changes the emitted srcset string. In practice this changes the image URL and therefore the cache key for the optimized asset.

Likely explanation

• The optimizer will trim candidates that exceed the source intrinsic width, but it cannot infer the rendered slot width. The 100vw fallback can therefore select a candidate wider than the slot, wasting bytes.
• Providing a correct sizes value gives the browser an accurate slot width per breakpoint, allowing it to pick a smaller candidate without touching the global size arrays.

Evidence that distinguishes optimizer limits from oversized candidates

1. Open Chrome DevTools Network panel, reload, and inspect the chosen image URL. Note the width in the URL and compare to the element’s computed rendered width.
2. View the rendered HTML srcset. It is the same with or without sizes; only the selection changes.
3. Measure bytes with Lighthouse or WebPageTest for the same viewport with sizes omitted vs sizes added. A large drop indicates a hint problem.
4. Check cache behavior after a config change. A different URL hash or CDN cache miss confirms cache key invalidation from deviceSizes/imageSizes changes.

Decision flow

1. Measure actual rendered width at key breakpoints.

2. Add a sizes attribute that matches the layout: fixed width/height with a media-query sizes string, or fill inside a sized parent with sizes="100vw" or the appropriate container width.

3. Verify selection improves. If the selected width now matches the slot within ~1 DPR, stop.

4. Only edit deviceSizes/imageSizes if you need fewer global candidates for all images and you can tolerate cache invalidation and increased CDN load. This is a support limit, not a free tuning knob.

Cautions: a sizes value that does not match the real width causes undersizing and quality loss. Modifying deviceSizes/imageSizes forces cache invalidation for affected images.

One missing detail that changes the recommendation: what layout mode is the Image component using — fixed width/height, responsive, or fill? The correct sizes string and whether a parent container constraint is required depends on that.