WebP vs AVIF en 2026: soporte, tamaño y código de respaldo

WebP vs AVIF en 2026: sirve AVIF primero con un respaldo en WebP o JPEG cuando puedas codificar por adelantado, y usa WebP solo cuando necesites una codificación rápida o un único formato sencillo. Los dos son Baseline ampliamente disponibles a octubre de 2026, así que el soporte de navegadores ya no decide. Las imágenes WebP tienen un límite de 16383 × 16383 px (preguntas frecuentes de WebP), que solo importa en panorámicas muy grandes. AVIF generó archivos más pequeños con la misma calidad visual en las pruebas publicadas por web.dev y admite HDR; WebP codifica mucho más rápido (web.dev, actualización de 2023). La diferencia en bytes depende de cada imagen, así que mídela con tus propias fotos antes de decidir.

WebP vs AVIF de un vistazo

Los dos formatos se diferencian más en coste y en funciones que en soporte. Los datos de soporte proceden de web-features 3.44.0 (22 de octubre de 2026); las demás filas proceden de los documentos de WebP de Google y de web.dev:

AVIF pasó a «recientemente disponible» en Baseline el 25 de enero de 2024, cuando Edge 121 lo añadió, y a «ampliamente disponible» 30 meses después, el 25 de julio de 2026. Si tus analíticas siguen mostrando una parte apreciable de navegadores anteriores a Safari 16 o Edge 121, mantén un respaldo.

Tamaño de archivo: ¿cuál pesa menos?

AVIF salió más pequeño en las comparativas publicadas por web.dev, pero el margen varía tanto que cualquier porcentaje concreto induce a error. La cifra de Google para WebP es de un 25 a 34% menos que JPEG. El artículo de web.dev sobre AVIF informa de «un ahorro superior al 50% frente a JPEG», advirtiendo de que el ahorro exacto depende del contenido, los ajustes de codificación y el objetivo de calidad, y la actualización de web.dev de 2023 citaba que Imgix veía un 60% de ahorro frente a JPEG y un 35% frente a WebP. Esas cifras salen de conjuntos de imágenes distintos, así que mide las tuyas.

Como los resultados dependen del contenido, prueba al menos tres tipos de imagen de tu propio sitio: una foto grande, una captura o gráfico con texto y una miniatura pequeña. Codifica cada origen con varios niveles de calidad y compara el tamaño del archivo con la calidad que aceptes, usando cwebp y avifenc de libavif:

# WebP, calidad 75
cwebp -q 75 hero.jpg -o hero.webp

# AVIF, calidad 60 como valor inicial para ajustar, con 8 hilos
avifenc -q 60 --jobs 8 hero.jpg hero.avif

ls -l hero.*

Squoosh hace lo mismo en el navegador con un deslizador de comparación lado a lado, más rápido para unas pocas imágenes.

Velocidad de codificación y herramientas

WebP se codifica más rápido, y eso importa cuando las imágenes se generan bajo demanda. La actualización de web.dev de 2023 dice que AVIF es el codificador más lento de los habituales para el uso al vuelo, aunque es competitivo con el esfuerzo por defecto cuando se codifica por adelantado. avifenc tiene un ajuste --speed de 0 (el más lento) a 10 (el más rápido), por defecto 6; las velocidades más altas cuestan eficiencia de compresión. web.dev informa de una codificación unas 5 veces más rápida con 8 hilos, sin describir la prueba.

En la práctica:

• Los pipelines de compilación (sitios estáticos, next/image con caché, un CDN de imágenes con caché) manejan bien AVIF, porque cada imagen se codifica una sola vez.
• El redimensionado al vuelo sin caché es donde la velocidad de WebP da ventaja.
• Subidas al CMS: comprueba que tu CMS acepta AVIF antes de cambiar el pipeline. WordPress acepta subidas AVIF desde la versión 6.5 (2024), pero solo si la biblioteca Imagick o GD del servidor lo soporta; Herramientas > Salud del sitio > Información > Gestión de medios muestra si es así (blog central de WordPress).

Servir los dos con un respaldo en picture

Usa el elemento <picture> para que cada navegador elija el primer formato que soporte, de arriba abajo, y recurra al <img>:

<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"
       srcset="hero-800.jpg 800w, hero-1600.jpg 1600w" sizes="100vw"
       width="1600" height="900" alt="Product on a desk">
</picture>

Tres detalles importan en los teléfonos:

• width y height en el <img> permiten al navegador reservar espacio antes de que llegue el archivo, lo que evita un desplazamiento de diseño al cargar la imagen.
• srcset con sizes hace que un teléfono de 390 px de ancho con relación de píxeles 2 elija el archivo de 800w en lugar del de 1600w (390 × 2 = 780 píxeles del dispositivo). Un teléfono con relación 3 necesita 1170 píxeles del dispositivo y toma el archivo de 1600w. Cómo dimensionar las imágenes para móviles se explica en cómo hacer un sitio web apto para móviles.
• alt, loading y fetchpriority van en el <img>, nunca en <source>.

Para fondos CSS, image-set() con type() hace lo mismo y es Baseline ampliamente disponible desde marzo de 2026:

.hero {
  background-image: image-set(
    url("hero.avif") type("image/avif"),
    url("hero.webp") type("image/webp"),
    url("hero.jpg") type("image/jpeg")
  );
}

Negociación de contenido en un CDN

Algunos CDN de imágenes eligen el formato a partir de la cabecera Accept de la petición en lugar de <picture> (consulta la documentación de tu CDN). Eso tiene una trampa en los iPhone. Según la lista de valores Accept por defecto de MDN (actualizada en octubre de 2026), Chrome y Edge 121+ envían image/avif,image/webp,... y Firefox también envía image/avif, mientras que el valor de Safari empieza por image/webp y no menciona AVIF. Un CDN que solo lee Accept enviará, por tanto, WebP a Safari, aunque Safari decodifica AVIF desde la 16.4. Si quieres AVIF en los iPhone, usa <picture> o comprueba cómo detecta tu CDN a Safari.

¿Qué pasa con JPEG XL?

JPEG XL todavía no es Baseline, así que necesita respaldo. A octubre de 2026 tiene soporte en Safari 17+ (solo imágenes fijas), Chrome 155, Firefox 158 (publicado el 13 de octubre de 2026, según sus notas de la versión) y Edge 155 (publicado el 8 de octubre de 2026, según sus notas de la versión). Samsung Internet no lo soporta, y MDN browser-compat-data 8.1.7 sigue marcando Edge como no soportado, así que web-features no lo lista como Baseline (MDN browser-compat-data). Se puede añadir como tercer <source> por encima de AVIF para los navegadores que lo soportan, a costa de una codificación más por imagen.

Cuándo JPEG sigue valiendo

Un JPEG bien comprimido es una opción razonable cuando:

• no puedes cambiar el marcado ni el proceso de compilación, y el CMS o el CDN no convierten formatos por ti;
• la imagen es una miniatura pequeña donde los bytes ahorrados son unos pocos kilobytes;
• el archivo está pensado para que los usuarios lo descarguen, lo envíen por correo o lo editen, donde JPEG funciona en todas las herramientas;
• ya sirves el tamaño correcto para cada dispositivo y la página supera su auditoría de imágenes.

En Lighthouse 13 (octubre de 2025), la antigua auditoría «Servir imágenes en formatos modernos» se integró en el insight de Entrega de imágenes (Chrome for Developers). Trátala como una pista de dónde están los mayores ahorros de la página; revisa las dimensiones de las imágenes antes que el formato. Cómo ejecutar la auditoría y leerla está en la guía de auditoría móvil con Lighthouse.

Comprueba el resultado en una página de tamaño móvil

Después de cambiar de formato, comprueba dos cosas: que cargan los archivos correctos y que el diseño no se ha movido. El panel Red de DevTools muestra el formato y el tamaño que usa realmente cada imagen; filtra por Img y mira la columna Type. Para la velocidad en datos de campo, usa los métodos de la guía de prueba de velocidad en móviles.

Para el diseño, abre la página en anchos de móvil. Mobile View Extension recarga la pestaña con el user agent, el tamaño de pantalla y la relación de píxeles de un teléfono, así que ves el diseño móvil con la versión real de la página. Solo muestra el diseño: no mide el peso de las imágenes ni el tiempo de carga, y se renderiza con el motor de Chrome de escritorio, así que la elección de formato de Safari hay que comprobarla en Safari.

Preguntas frecuentes

¿Es AVIF mejor que WebP?

En cuanto a tamaño de archivo, sí en las pruebas publicadas: AVIF generó archivos más pequeños que JPEG y WebP con calidad visual similar en las comparativas de web.dev, y admite HDR. Compruébalo con tus propias imágenes, porque la diferencia depende del contenido. WebP es mejor cuando importa la velocidad de codificación o cuando tus herramientas no manejan AVIF.

¿Soportan todos los navegadores AVIF en 2026?

Todos los navegadores principales actuales lo soportan. AVIF es Baseline ampliamente disponible desde el 25 de julio de 2026, con soporte desde Chrome 85, Firefox 113, Safari 16.4 (Safari iOS 16.1) y Edge 121.

¿Debo seguir usando WebP?

Sí, como respaldo después de AVIF, o como único formato moderno si tu pipeline codifica las imágenes bajo demanda. WebP está soportado en todos los navegadores principales desde Safari 14, en 2020.

¿Perjudica AVIF al SEO?

No. La Búsqueda de Google incluye AVIF entre sus formatos de imagen compatibles, junto a WebP, JPEG, PNG, GIF, BMP y SVG (Google Search Central, actualizado en marzo de 2026). La página no describe el formato como una señal de posicionamiento.