Durante los primeros meses de esta reconstrucción tenía un pequeño script de Node que corría antes de cada build: leía cada imagen en src/assets, la redimensionaba a tres anchos, escribía copias en .webp y esperaba haberme acordado de ejecutarlo antes de hacer push. Funcionaba, en el sentido de que nunca fallaba. También significaba que cada import de imagen era un acto de fe en que el archivo redimensionado realmente existía.
Lo que estaba evitando
El componente <Image /> integrado de Astro hace exactamente lo que hacía mi script, salvo que corre como parte del propio build, lo que significa que una imagen faltante o demasiado grande es un fallo de build en lugar de un bug ya publicado. Evité el cambio durante meses porque “mi script ya funciona” me parecía una razón suficiente para no tocarlo.
---
import { Image } from 'astro:assets';
import cover from '../assets/cover.jpg';
---
<Image src={cover} width={800} alt="Post cover" />Hacer el cambio tomó unos cuarenta minutos, la mayoría de los cuales fueron para borrar el script viejo y sus dos dependencias de npm. El build se volvió un poco más lento —Astro hace más trabajo por imagen que mi script— pero el despliegue se volvió más rápido, porque Cloudflare Pages ahora servía salidas .webp pre-optimizadas en los anchos exactos que cada plantilla realmente pide, en lugar de los tres tamaños fijos que había adivinado ocho meses antes.
Lo que realmente aprendí
La lección no fue sobre formatos de imagen. Fue que “ya funciona” hace mucho trabajo no remunerado como razón para no adoptar algo. Mi script funcionaba. También carecía de manejo de errores, de un srcset responsivo, y vivía enteramente en mi cabeza. La versión del framework hace más, lo hace más correctamente, y no tengo que acordarme de ejecutarla.