sizes=auto ya es Baseline: y nuestro propio blog no tiene ni un srcset

Sí, sizes="auto" está listo para producción: Safari 27 cerró el último hueco en septiembre de 2026 y la función entró en Baseline Newly available, así que el navegador puede usar el ancho real del elemento para elegir la variante de srcset en cualquier imagen con loading="lazy". Pero esa no es la parte interesante de hoy. Auditamos en directo el artículo que publicamos ayer en mintec.co y encontramos 8 imágenes, 1,16 MB de JPEG, 0 atributos srcset, 0 atributos sizes y 0 imágenes con loading="lazy". No hacía falta borrar ninguna matemática: todavía no había candidatos entre los que elegir. El orden correcto de trabajo es candidatos → lazy → auto, y este es el número que lo justifica.

Lo que cambió: el navegador ya se conoce su propio layout

Durante diez años, sizes fue una estimación escrita a mano: declarabas cuánto mide la imagen en pantalla para que el navegador calculara qué candidato de srcset descargar. La estimación vive en el HTML, se quedó obsoleta con cada rediseño y falla exactamente en los sitios con rejillas, que son los que más imágenes tienen.

Safari 27 publicó el soporte de auto en su nota de versiones y web.dev lo recogió en el resumen de septiembre como una de las funciones que alcanzaron Baseline Newly available ese mes. Según los datos de compatibilidad de MDN, la versión mínima es Chrome 126, Firefox 150 y Safari 27.

Hay dos matices que los artículos de lanzamiento suelen dejar fuera:

• Nuevo no es igual a instalado. Safari 27 se publicó en septiembre de 2026. En octubre, una parte grande de los usuarios de Safari todavía corre una versión anterior, y esas versiones no entienden auto. Por eso MDN recomienda declarar un valor de respaldo: sizes="auto, (max-width: 40em) 100vw".
• Safari 27 tiene una implementación parcial. MDN marca partial_implementation: las imágenes SVG con sizes="auto" y object-fit se distorsionan (bug 324661). En un blog con SVG inline como icono, esa combinación no se usa; en una galería vectorial, sí.

Qué dice exactamente la especificación

El texto de la especificación HTML es más restrictivo de lo que resume el titular:

• Un <img> permite auto-sizes solo si su loading está en estado lazy y el valor de sizes es auto o empieza por auto, (sin distinguir mayúsculas).
• Si la condición no se cumple, el valor auto se ignora y se usa el siguiente valor de la lista. Ese es el mecanismo que hace que la lista de respaldo funcione: en un navegador viejo o en una imagen eager, cae al valor manual.
• sizes="auto" implica contain-intrinsic-size: 300px 150px. Sin width y height, la imagen ocupa una caja de 300x150 hasta que carga. La especificación lo dice sin rodeos: declara las dimensiones.
• Si el <img> permite auto-sizes, los <source> hermanos anteriores pueden omitir sizes, y equivale a declarar auto. Art direction y resolución comparten el mismo atajo.
• El navegador guarda el último ancho observado y puede re-elegir candidato cuando cambia el entorno (resize) mientras la imagen lazy todavía no ha cargado.

Nada de esto es nuevo para quien lea la especificación. Lo nuevo es que las tres motorizaciones ya lo cumplen.

Auditamos nuestro propio artículo: 1,16 MB y ni un srcset

Ayer publicamos nuestra medición real de JPEG XL sobre 598 archivos del sitio: 22,9% de ahorro sin pérdida y, de paso, 34 archivos .jpg que nunca fueron JPEG. El formato ya estaba medido. Lo que no habíamos mirado era la capa de selección.

Cogimos el artículo recién publicado, /blog/jpeg-xl-chrome-155-transcoding/, y contamos el HTML servido por la CDN el 10 de octubre de 2026:

Repetimos en la portada, en /blog/ y en /services/: cero srcset en todas ellas. La única página con srcset en el sitio es un artículo que enseña srcset dentro de un bloque de código.

Dos conclusiones incómodas:

1. Un visitante desde un teléfono de 390 px descarga exactamente los mismos bytes que un monitor de 27 pulgadas, y los descarga eagerly, en competencia directa con la imagen LCP.
2. La capa de formato tampoco existe: pedimos AVIF y WebP en la cabecera Accept y la CDN devuelve JPEG con Cache-Control: public, max-age=604800. En la guía AVIF vs WebP para Astro medimos entre 40% y 60% menos de peso en las migraciones de clientes; aquí no hay nada que negociar.

Por qué no tenemos srcset: la configuración por defecto de Astro

No es descuido del template, es el valor por defecto. En el node_modules de nuestro propio proyecto (Astro 5.16.15), internal.js solo calcula widths y sizes si layout no es none:

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

Con layout: "none" no hay widths, no hay sizes y, por tanto, no hay srcset. Y cuando sí hay layout, getSizesAttribute devuelve esto:

La propia documentación de Astro lo admite: el valor generado asume que la imagen se muestra casi a todo el ancho cuando el viewport es menor que la imagen, y avisa de que hay que ajustarlo a mano cuando la imagen vive en una columna estrecha.

El cálculo que ya no tienes que hacer

La aritmética es determinista, no necesita laboratorio. Una tarjeta de 400 px en un viewport de 1440 px con DPR 2, con sizes="100vw":

• tamaño de origen declarado: 1440 px → objetivo en píxeles de dispositivo: 2880 px;
• candidato real necesario: 400 × 2 = 800 px;
• el navegador elige el candidato más grande de la lista y descarga 3,6× más píxeles de los que va a pintar, y esos píxeles también hay que decodificarlos y guardarlos en memoria.

Con sizes="auto" el navegador mide los 400 px del elemento, aplica el DPR y elige el candidato de 800 px sin que nadie escriba una media query. La matemática pasa del HTML, que envejece, al navegador, que se actualiza solo.

Marco de decisión: dónde va auto y dónde no

Lo que cambiamos esta semana

La opinión, después de los datos: auto debería ser el valor por defecto de cualquier imagen de rejilla, y el sizes manual sobrevive solo en el hero. El error no estaba en nuestra estimación, porque no había estimación que estimar; estaba en no haber encendido la capa de selección.

Por orden, y sin saltarnos ninguno:

1. Emitir candidatos. Poner layout: "constrained" en las tarjetas y las imágenes de artículo, o pasar widths explícitos. Sin srcset, auto no tiene nada que elegir.
2. Marcar lazy. En Astro es el valor por defecto salvo que se use priority, que fuerza eager + fetchpriority="high" + decoding="sync". Ese es el camino del hero, no el de las tarjetas.
3. Declarar sizes="auto" con respaldo en todo lo lazy, más width y height con las dimensiones de la imagen más grande del srcset.
4. Dejar el sizes manual solo donde la selección es previa al layout: hero, imágenes fijas y bloques con ancho conocido por CSS.
5. Medir otra vez. El presupuesto de rendimiento que usamos en sitios multimedia no contempla bytes de selección equivocada; hay que sumarlo a la capa de formato que ya revisamos en la auditoría de medios para IA.

Y una nota de honestidad operativa: esto también cambia el artículo de ayer. Cuando las tarjetas tengan srcset, el hero seguirá sin competir por ancho de banda con cuatro JPEG de 300 KB, y lo que medimos sobre JPEG XL empezará a notarse en la página real, no solo en la carpeta. El formato decide cuánto pesa cada candidato; sizes="auto" decide cuántos candidatos se descargan. Son dos capas, y este mes las dos cambiaron: la de formatos con JPEG XL en Chrome 155 y Firefox, la de selección con Safari 27.

Lo mismo aplica al vídeo: el patrón adaptativo de Astro ya declara sizes a mano en sus fuentes, y ahí auto solo entra cuando el elemento es lazy. La regla no cambia: medir primero, estimar solo si hace falta.