WebP y AVIF: qué formato de imagen usar y cómo servirlo sin tirar kilobytes

El WebP vs AVIF no es la decisión que más pesa: en 2026 ambos formatos superan el 96% de soporte y su diferencia real en producción es menor de lo que prometen los benchmarks. Lo que sí mueve la aguja es servir el archivo correcto al tamaño correcto.

Este artículo va en ese orden: el peso primero, donde está el ahorro; después los formatos, con sus números y costes; y al final la entrega, donde se pierde buena parte de lo ganado. La indexación de imágenes la tratamos en la guía de Google Imágenes; aquí el tema son los kilobytes.

El peso de las imágenes es tu palanca más grande

De todo lo que descarga una página, las imágenes son casi siempre el bloque más pesado y el más fácil de recortar: no rompen el diseño ni dependen de terceros.

Los números reales de la web

El capítulo Media del Web Almanac 2024 mide qué se sirve de verdad en móvil: JPEG 32,4%, PNG 28,4%, GIF 16,8%, WebP 12% y AVIF apenas 1,0%. JPEG perdió 8 puntos desde 2022 y AVIF creció cerca de un 386% relativo en dos años, pero la lectura práctica es que la mayoría de la web sigue entregando formatos de los años noventa.

La imagen más pesada: 135 KB de mediana

En una página móvil típica la imagen más grande pesa 135 KB en la mediana y 1.002 KB en el percentil 90, mientras la mediana de todas las imágenes es de 12 KB. No es un problema de imágenes en general: son dos o tres, casi siempre el hero o la foto del producto. La pestaña Network ordenada por tamaño y la auditoría "Properly size images" de Lighthouse te dan la lista en minutos.

Bits por píxel: la única comparación justa

Cualquier formato se comprime hasta verse mal, así que comparar pesos sueltos es trampa. La métrica honesta es bits por píxel a calidad comparable: GIF 6,7, PNG 3,8, JPEG 2,0, AVIF 1,4 y WebP 1,3 en sitios reales. Ese último par es el detalle incómodo: AVIF solo baja a 1,4 porque los codificadores actuales priorizan calidad.

WebP, AVIF, JPEG y PNG: qué hace cada formato

Tres preguntas deciden casi todo: ¿fotografía o ilustración?, ¿transparencia?, ¿cuánto puedes gastar codificando? La guía general de optimización de imágenes cubre lo básico; aquí bajamos un nivel.

JPEG y PNG: cuándo siguen siendo la respuesta correcta

JPEG sigue siendo razonable para fotografía cuando el pipeline no genera variantes y para el src de respaldo de un <picture>. PNG sobrevive por transparencia con bordes duros y capturas con texto: con zonas planas, un PNG bien exportado puede pesar menos que un WebP comprimido de más.

WebP: el valor seguro

web.dev documenta reducciones del 25-35% frente a JPEG y hasta el 80% frente a PNG: Facebook ahorró esos porcentajes y YouTube logró cargas un 10% más rápidas con miniaturas WebP. Tiene 97,08% de soporte global y codifica rápido. Si tu documentación dice que "WebP aún no es compatible con todos los navegadores", ese dato caducó.

AVIF: más compresión, con coste

AVIF usa el códec AV1: web.dev describe mejor calidad perceptual con archivos más pequeños que JPEG o WebP, y el soporte ya es del 96,33% global (Chrome y Opera 2020, Firefox 2021, Safari 2022). El coste es real: codificar es lento, decodificar gasta CPU en móviles antiguos y un navegador sin soporte descarta la imagen sin mostrar nada. Nunca lo pongas como único src.

WebP vs AVIF: cómo decidir según el tipo de imagen

Fotografía frente a ilustración y texto

En fotografía con degradados suaves AVIF gana de forma consistente. En ilustraciones planas, logotipos y capturas con texto pequeño la ventaja se reduce: ambos manejan bien las zonas planas y el texto nítido castiga a los dos igual. En foto de producto compara AVIF y WebP; en capturas de interfaz compara los tres.

Transparencia, animación y calidad visible

Los dos admiten transparencia y animación, así que un GIF de 4 MB ya no tiene excusa. Donde se nota la compresión es en texturas: caras, tejidos, cielos con degradado. Ahí AVIF aguanta mejor y WebP empieza a mostrar bandas. Si tu imagen tiene una cara grande, ese es el criterio, no el porcentaje de ahorro.

El coste que nadie mide: codificación y pipeline

Generar AVIF cuesta varias veces más CPU que WebP. Si publicas veinte imágenes al día y codificas al vuelo, se nota en la factura y en los tiempos de subida: mejor codificar una vez al subir. Y ojo con el almacenamiento, porque cada formato y cada ancho multiplican archivos; si el volumen crece, una CDN que transforme imágenes en el borde puede salir más barata.

Cómo servir AVIF y WebP (y JPEG al resto)

picture con type: el orden manda

El navegador recorre los <source> en orden y se queda con el primero que entiende: el más moderno va primero, el respaldo al final.

<picture>
  <source type="image/avif" srcset="hero-800.avif 800w, hero-1600.avif 1600w" sizes="100vw">
  <source type="image/webp" srcset="hero-800.webp 800w, hero-1600.webp 1600w" sizes="100vw">
  <img src="hero-800.jpg" alt="Descripcion concreta" width="1600" height="900">
</picture>

Si inviertes el orden, sirves JPEG a todos y el trabajo de codificar AVIF no sirve de nada.

El src del img no es decorativo

Google Search Central admite en el src BMP, GIF, JPEG, PNG, WebP, SVG y AVIF, y recomienda <picture> y srcset, pero recuerda que hay rastreadores que no los interpretan: el src debe ser una imagen real y accesible. La duda "¿Google lee AVIF?" está cerrada: sí.

srcset y sizes: donde se pierde el ahorro

Descriptores w frente a x

Con w declaras el ancho real de cada archivo y el navegador calcula cuál necesita, pero para eso necesita saber cuánto ocupa la imagen en la maquetación: eso es sizes. Con x declaras densidades y asume el tamaño del CSS. El Almanac mide 62-64% de uso de w frente a 15% de x, con srcset en el 42% de las páginas móviles.

El dato incómodo: 180 KB tirados

La mediana de sizes es un 16% demasiado grande en móvil y un 43% en escritorio. Uno de cada cinco sizes de escritorio es tan inexacto que el navegador elige un recurso peor, y un 25% de las páginas con w cargan 180 KB o más de imagen desperdiciada. Una imagen en una columna de 300 píxeles con sizes="100vw" hace que baje la variante de 1600. RespImageLint los señala.

sizes="auto" y su soporte real

sizes="auto" deja que el navegador use el ancho ya calculado y es ideal con loading="lazy". Su soporte es del 74,64%: Chrome y Edge 126 o superior, Firefox 150 o superior y Safari 27 solo parcial. Como mejora progresiva sirve; como base de todo el sitio, todavía no.

La imagen principal: donde el orden de carga decide el LCP

Nunca lazy en la imagen del hero

web.dev es tajante: nunca hagas lazy loading de tu imagen LCP. Añadir lazy al hero retrasa su descubrimiento y siempre empeora el LCP; el lazy va bajo el pliegue. Qué elemento es el LCP lo explicamos en la guía de LCP, y el detalle en la guía de lazy loading.

fetchpriority, preload y dimensiones

Si la imagen principal está en el HTML, basta con fetchpriority="high"; si solo se referencia desde CSS o JavaScript, adelántala con <link rel="preload" as="image" fetchpriority="high" type="image/webp" href="/hero.webp">. Marcar más de una o dos imágenes como prioritarias anula el efecto. Y declara width y height: sin ellos el navegador no reserva espacio y la imagen empuja el contenido, que es CLS.

Checklist para bajar el peso esta semana

Del inventario al antes/después

1. Ordena Network por tamaño y anota las tres imágenes más pesadas.
2. Compara su ancho real con el ancho en que se muestran (x2 en pantallas densas).
3. Recorta: 1600 píxeles cubren casi cualquier hero.
4. Codifica WebP como base y AVIF para las fotos grandes.
5. Añade srcset con tres a cinco anchos y calcula sizes con la maquetación real.
6. Quita lazy del hero y ponle fetchpriority="high".
7. Vuelve a medir y anota el antes y el después en kilobytes.

Cuatro errores que cuestan más que el formato

Uno: servir 4000 píxeles para un hueco de 800, que multiplica el peso por veinticinco. Dos: recomprimir un JPEG ya comprimido, que suma artefactos y kilobytes. Tres: seguir usando GIF animado, el formato más caro por píxel. Cuatro: ignorar la densidad de píxel y servir una sola resolución.

Cambiar de formato sin arreglar dimensiones y entrega es cambiar de problema. Hazlo en este orden y el ahorro se ve en el peso de la página, no en un ranking prometido. Para medir el efecto real, los datos de campo mandan: es la diferencia que explicamos en PageSpeed Insights y sus dos tipos de datos.