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

With next/image, omitting the sizes attribute leaves the browser without a layout hint, so it falls back to 100vw while Next.js still emits a srcset built from images.deviceSizes and images.imageSizes. This often causes the browser to select a candidate wider than the rendered slot, wasting bytes even though the optimizer is active.

The candidate widths are controlled by images.deviceSizes and images.imageSizes in next.config.js, but changing them alters emitted srcset entries and cache keys, making them a support limit rather than a free tuning knob. Because Next.js cannot infer the actual slot width, the correct sizes value remains a per-breakpoint design decision: a fixed width/height with a sizes media-query string, or fill inside a sized parent with sizes, each with different trade-offs.

Before tuning, it is unclear whether the bottleneck is the optimizer itself or simply oversized candidates caused by a missing or incorrect sizes hint. What evidence distinguishes these cases, and how should a team decide between adjusting the layout approach and editing deviceSizes or imageSizes when cache keys change with the candidate set?