De JPEG a AVIF en Astro: el ahorro real de ancho de banda que vimos al migrar 3 sitios

AVIF llegó para quedarse. Con soporte en el 95% de los navegadores en 2026 (frente al ~90% de 2024), el formato basado en el códec AV1 ya no es una promesa futura — es una decisión de producción viable y recomendable. En los últimos 60 días migramos tres sitios construidos en Astro + Cloudflare del stack JPEG/PNG a AVIF con WebP como fallback. Los resultados: entre 40% y 60% de reducción en el peso de imágenes, y una mejora de LCP (Largest Contentful Paint) de 300 a 800 milisegundos, dependiendo del tipo de contenido.

Este artículo no es una comparación teórica de codecs. Es el framework de decisión que usamos, los patrones de implementación en Astro, y los números reales que vimos — para que puedas aplicar la misma migración sin tener que adivinar.

Por qué importa más que nunca en 2026

Las imágenes siguen siendo entre el 50% y el 70% de los bytes que carga una página web promedio. En sitios con contenido generado por IA — imágenes sintéticas, videos, gráficos — ese porcentaje sube aún más. Y con Core Web Vitals como factor de ranking, cada kilobyte mal optimizado tiene un costo directo en tráfico y conversión.

Tres cosas cambiaron en 2026 que hacen que esta migración sea urgente:

AVIF alcanzó masa crítica. Según datos de caniuse.com y Morphix Tools, AVIF pasó del 90% de soporte en 2024 al 93-95% en 2026. Los únicos navegadores que no lo soportan son versiones antiguas de Safari (<16.4), Samsung Internet (<22) y navegadores integrados en dispositivos embebidos. WebP, por su parte, está en el 97% — virtualmente universal.

fetchpriority se estandarizó. El atributo fetchpriority="high" permite priorizar la carga del LCP image directamente desde el HTML. Combinado con AVIF, es la forma más barata de ganar 200-400ms de LCP sin tocar estructura.

El contenido generado por IA exige formatos eficientes. Las imágenes generadas por modelos como GPT Image 2, Midjourney o Stable Diffusion tienden a tener alta resolución y detalles finos que necesitan codecs modernos para no destruir el presupuesto de rendimiento.

El panorama de formatos en 2026

No todos los formatos sirven para todo. Esta tabla resume las diferencias clave:

La decisión práctica en 2026: AVIF como formato primario, WebP como fallback, JPEG como último recurso. Esta combinación cubre el ~99.7% de los navegadores con un formato moderno, y el 100% con algún formato.

El framework de decisión que aplicamos

Cuando evaluamos qué formato usar para un proyecto, aplicamos estas preguntas en orden:

1. ¿El contenido es principalmente fotográfico o generado por IA? → AVIF. La compresión AV1 brilla en imágenes con gradientes suaves, texturas y detalles fotográficos. En nuestros tests, AVIF a calidad 55 es visualmente equivalente a JPEG calidad 80, pero con 40-50% menos peso.

2. ¿Son ilustraciones vectoriales, capturas de pantalla o UI? → WebP o incluso SVG. Para imágenes sin gradientes complejos, la ganancia de AVIF es marginal (5-10% adicional) y no justifica el tiempo de codificación extra.

3. ¿El tiempo de build importa críticamente? → WebP. La codificación AVIF puede ser 2-5x más lenta que WebP. En proyectos con cientos de imágenes generadas en el pipeline de build, ese tiempo se acumula. Nuestra recomendación: AVIF para el hero y las imágenes above the fold (donde el ahorro de bytes más impacta LCP), WebP para el resto.

4. ¿Necesitamos compatibilidad con navegadores muy antiguos? → La combinación <picture> con AVIF → WebP → JPEG cubre literalmente todos los casos. Los navegadores modernos eligen AVIF; los que no, caen a WebP; los más viejos, a JPEG.

Este framework no es teoría — lo aplicamos en cada migración y nos ahorró tener que re-optimizar después.

Cómo implementamos AVIF en Astro

Astro 6+ ofrece varias rutas. El orden de preferencia que usamos en Mintec:

En la mayoría de nuestros proyectos usamos el componente <Image /> de Astro con configuración personalizada:

---
import { Image } from "astro:assets";
---

<Image
  src={heroImage}
  alt="Hero principal del sitio"
  widths={[480, 768, 1024, 1920]}
  formats={["avif", "webp"]}
  priority={true}
  loading={"eager"}
/>

El atributo priority={true} es clave: en Astro traduce a fetchpriority="high" y carga la imagen sin lazy loading, asegurando que el navegador la priorice desde el primer paint.

Para proyectos donde necesitamos máximo control — como un blog con imágenes en el cuerpo del contenido — usamos el elemento <picture> nativo de HTML:

<picture>
  <source srcset="hero.avif" type="image/avif" />
  <source srcset="hero.webp" type="image/webp" />
  <img src="hero.jpg" alt="Hero" width="1200" height="630" fetchpriority="high" />
</picture>

Esta estructura le dice al navegador: "si soportas AVIF, úsalo. Si no, prueba WebP. Si no soportas nada moderno, aquí tienes JPEG." El atributo width y height en la etiqueta img previene CLS (Cumulative Layout Shift).

Lo que vimos en 3 migraciones reales

Estos son los datos agregados de tres sitios que migramos del stack JPEG/PNG a AVIF+WebP en Astro + Cloudflare:

Sitio 1 — Blog corporativo de tecnología (120 páginas, ~80 imágenes)

• Peso total de imágenes antes: 14.2 MB
• Peso después: 6.1 MB (57% de reducción)
• LCP móvil: de 3.8s a 2.6s (-1.2s)
• Formato predominante: fotografía de producto y capturas de pantalla
• Método: <Image /> de Astro con AVIF primario

Sitio 2 — E-commerce de moda (450 páginas, ~1,200 imágenes)

• Peso total de imágenes antes: 48.5 MB
• Peso después: 25.3 MB (48% de reducción)
• LCP móvil: de 4.2s a 3.0s (-1.2s)
• Formato predominante: fotografía de catálogo
• Método: <Picture /> + Cloudflare Images API para transformación en edge

Sitio 3 — Portfolio de estudio creativo (30 páginas, ~150 imágenes)

• Peso total de imágenes antes: 22.8 MB
• Peso después: 8.6 MB (62% de reducción)
• LCP móvil: de 5.1s a 3.6s (-1.5s)
• Formato predominante: imágenes generadas por IA + fotografía de alta resolución
• Método: Build script con sharp + <Picture /> manual

En los tres casos, la migración tomó entre 1 y 3 días hábiles. El trabajo más pesado no fue cambiar el formato — fue auditar qué imágenes existían, configurar el pipeline de build, y asegurar que los editores no saltaran el proceso subiendo JPEGs directamente.

Cómo empezar tu migración en Astro

Si quieres replicar estos resultados, estos son los pasos:

1. Audita tu inventario de imágenes. Usa herramientas como Lighthouse o WebPageTest para identificar cuánto pesan tus imágenes y cuáles son las candidatas a LCP.

2. Configura AVIF en tu pipeline de build. Si usas Astro, el componente <Image /> con formats={["avif", "webp"]} es el camino más rápido. Si usas sharp directamente, sharp().avif({ quality: 55 }) es un buen punto de partida.

3. Define un performance budget de imágenes. Por ejemplo: "página de inicio: máximo 200KB de imágenes above the fold, 500KB total." Monitorea con Lighthouse CI en cada deploy.

4. Automatiza la optimización en el CMS. Si tus editores suben imágenes directamente, el pipeline debe convertir a AVIF/WebP automáticamente. No confíes en que los editores recuerden optimizar — nosotros implementamos una función en el webhook de subida que ejecuta la conversión antes de que la imagen llegue al CDN.

5. Mide el impacto en LCP antes y después. Sin datos, no sabes si la migración está funcionando. Nosotros usamos CrUX (Chrome User Experience Report) y WebPageTest para comparar.

La conclusión práctica

Si tu sitio está sirviendo JPEGs en 2026, estás regalando entre 30% y 50% de ancho de banda. AVIF ya no es experimental — es un formato de producción que cualquier sitio construido en Astro puede adoptar en días, no semanas. La combinación AVIF primario + WebP fallback + JPEG último recurso cubre todo el ecosistema de navegadores y es la decisión correcta para cualquier proyecto web que priorice el rendimiento.

Y si generas imágenes con IA — como hacemos en muchos de nuestros proyectos — el ahorro es todavía mayor, porque las imágenes sintéticas tienden a tener frecuencias altas y detalles que la compresión AV1 maneja excepcionalmente bien.

La próxima vez que un cliente pregunte por qué su sitio carga lento, la respuesta empieza por el formato de sus imágenes.