sizes=auto Is Baseline — and our own blog ships no srcset at all

Yes, sizes="auto" is production-ready: Safari 27 closed the last gap in September 2026 and the value reached Baseline Newly available, so the browser can use an element's real layout width to pick the srcset candidate on any image with loading="lazy". That is not the interesting part today. We audited the article we published yesterday on mintec.co and found 8 images, 1.16 MB of JPEG, 0 srcset attributes, 0 sizes attributes and 0 images with loading="lazy". There was no math to delete: there were no candidates to choose from. The correct order of work is candidates → lazy → auto, and this is the number that justifies it.

What changed: the browser now knows its own layout

For ten years, sizes was a hand-written estimate: you declared how wide the image would render so the browser could calculate which srcset candidate to download. The estimate lives in the HTML, it went stale with every redesign, and it fails exactly on grid layouts — which are the pages with the most images.

Safari 27 shipped support for auto in its release notes, and web.dev picked it up in the September round-up as one of the features that reached Baseline Newly available that month. MDN's compatibility data puts the floor at Chrome 126, Firefox 150 and Safari 27.

Two details the launch posts usually leave out:

• Newly available is not installed. Safari 27 shipped in September 2026. In October a large share of Safari users still run an earlier version, and those versions do not understand auto. That is why MDN recommends declaring a fallback: sizes="auto, (max-width: 40em) 100vw".
• Safari 27 is a partial implementation. MDN marks it partial_implementation: SVG images with sizes="auto" and object-fit are distorted (bug 324661). A blog with inline SVG icons never hits that combination; a vector gallery does.

What the specification actually says

The HTML specification is stricter than the headline suggests:

• An <img> allows auto-sizes only if its loading attribute is in the Lazy state and its sizes value is auto or starts with auto, (ASCII case-insensitive).
• If the condition is not met, the auto value is ignored and the next source size in the list is used. That is the mechanism that makes the fallback work: in an old browser or on an eager image, it falls back to the manual value.
• sizes="auto" implies contain-intrinsic-size: 300px 150px. Without width and height, the image occupies a 300x150 box until it loads. The specification says it plainly: declare the dimensions.
• If the <img> allows auto-sizes, preceding sibling <source> elements may omit sizes, which is equivalent to declaring auto. Art direction and resolution switching share the same shortcut.
• The browser keeps the last observed width and can re-select the candidate when the environment changes (resize) while the lazy image has not loaded yet.

None of this is news to anyone who reads the spec. What is new is that all three engines now implement it.

We audited our own article: 1.16 MB and no srcset

Yesterday we published our real JPEG XL measurement across 598 files on the site: 22.9% savings at zero quality loss and, on the way, 34 .jpg files that were never JPEGs. The format was measured. The selection layer was not.

We took the freshly published article, /blog/jpeg-xl-chrome-155-transcoding/, and counted the HTML served by the CDN on October 10, 2026:

We repeated it on the homepage, on /blog/ and on /services/: zero srcset on all of them. The only page on the site containing srcset is an article that teaches srcset inside a code block.

Two uncomfortable conclusions:

1. A visitor on a 390 px phone downloads exactly the same bytes as a 27-inch monitor, and downloads them eagerly, competing directly with the LCP image.
2. The format layer does not exist either: we ask for AVIF and WebP in the Accept header and the CDN returns JPEG with Cache-Control: public, max-age=604800. In the AVIF vs WebP guide for Astro we measured 40% to 60% less payload on client migrations; here there is nothing to negotiate.

Why we have no srcset: Astro's default configuration

It is not template negligence, it is the default value. In our own project's node_modules (Astro 5.16.15), internal.js only computes widths and sizes when layout is not none:

const layout = options.layout ?? imageConfig.layout ?? "none";
if (layout !== "none") {
  resolvedOptions.widths ||= getWidths({ width, layout, ... });
  resolvedOptions.sizes  ||= getSizesAttribute({ width: resolvedOptions.width, layout });
}

With layout: "none" there is no widths, no sizes and therefore no srcset. And when a layout is set, getSizesAttribute returns this:

Astro's own documentation admits it: the generated value assumes the image is displayed close to the full width of the screen when the viewport is smaller than the image, and it warns that you may need to adjust it manually when the image sits in a narrow column.

The math you no longer have to do

The arithmetic is deterministic, it does not need a lab. A 400 px card in a 1440 px viewport at DPR 2, with sizes="100vw":

• declared source size: 1440 px → target in device pixels: 2880 px;
• candidate actually needed: 400 × 2 = 800 px;
• the browser picks the largest candidate in the list and downloads 3.6× more pixels than it will paint, and those pixels also have to be decoded and held in memory.

With sizes="auto" the browser measures the element's 400 px, applies the DPR and picks the 800 px candidate with nobody writing a media query. The math moves out of the HTML, which ages, and into the browser, which updates itself.

Decision framework: where auto goes and where it does not

What we are changing this week

The opinion, after the data: auto should be the default for any grid image, and hand-written sizes only survives in the hero. Our estimate was not wrong — there was no estimate at all. The failure was not turning the selection layer on.

In order, and without skipping a step:

1. Emit candidates. Set layout: "constrained" on cards and article images, or pass explicit widths. With no srcset, auto has nothing to choose from.
2. Mark lazy. It is Astro's default unless you use priority, which forces eager + fetchpriority="high" + decoding="sync". That is the hero path, not the card path.
3. Declare sizes="auto" with a fallback on everything lazy, plus width and height with the intrinsic size of the largest image in the srcset.
4. Keep manual sizes only where selection happens before layout: hero, fixed images, blocks with a CSS-known width.
5. Measure again. The performance budget we use on media-heavy sites does not account for bytes spent on a wrong candidate; it has to join the format layer we already revisit in the rich-media performance review.

And an honesty note: this changes yesterday's article too. Once the cards have srcset, the hero stops competing for bandwidth with four 300 KB JPEGs, and what we measured on JPEG XL starts showing up on the real page instead of only in the folder. The format decides how much each candidate weighs; sizes="auto" decides how many candidates get downloaded. Two layers, and both moved this month: formats with JPEG XL in Chrome 155 and Firefox, selection with Safari 27.

The same rule covers video: the Astro adaptive pattern still declares sizes by hand on its sources, and auto only enters when the element is lazy. The rule does not change: measure first, estimate only if you have to.