Qué son AVIF y WebP
WebP es el formato de imagen de Google, presentado en 2010. Su modo con pérdida comprime una imagen igual que el códec de vídeo VP8 comprime un fotograma; un modo sin pérdida aparte, VP8L, está pensado para gráficos de bordes nítidos y pocos colores. Los dos modos admiten transparencia, y el WebP animado puede sustituir al GIF.
AVIF (AV1 Image File Format) guarda un fotograma comprimido con AV1, el códec de vídeo sin regalías de la Alliance for Open Media, dentro de un contenedor HEIF. Su especificación 1.0 se publicó en 2019. Las herramientas de codificación de AV1 son una década más modernas que las de VP8, así que AVIF conserva más detalle por byte en fotografías, y añade color de 10 y 12 bits y HDR. El precio es el tiempo de codificación: generar un AVIF cuesta bastante más CPU que un WebP de la misma imagen, y por eso los servicios de imágenes convierten una vez y guardan el resultado en caché.
La compatibilidad ya no es la pregunta decisiva. Según caniuse.com (datos del 30 de septiembre de 2026), alrededor del 97% de los navegadores en uso muestran WebP y alrededor del 95%, AVIF. WebP funciona desde Chrome 32, Firefox 65 y Safari 14 (en macOS 11 o posterior); AVIF, desde Chrome 85, Firefox 93, Safari en iOS 16, Safari 16.4 en Mac (imágenes estáticas desde Safari 16.1, en macOS 13 Ventura o posterior) y Edge 121. Ese pequeño porcentaje restante explica por qué sigue importando tener una alternativa, y con la negociación en el servidor esa alternativa no cuesta nada.
¿Cuál pesa menos? Depende de la imagen
La mayoría de las comparativas dan una sola cifra, "WebP pesa un 30% menos" o "AVIF reduce tus imágenes a la mitad", promediada sobre fotografías. Un sitio real también sirve capturas de pantalla, logotipos e iconos, y ahí el orden puede invertirse. El 5 de octubre de 2026 pasamos cuatro imágenes por el optimizador de imágenes que hay detrás de CDN.com.tr, con su configuración de producción, y contamos los bytes que produjo cada formato.
Foto de noticias, JPEG, 1920×1080. Original 262.025 bytes; JPEG optimizado 186.137; WebP 113.860; AVIF 86.936. El caso de manual: WebP pesa un 39% menos que el JPEG optimizado y AVIF otro 24% menos que WebP, un tercio de los bytes del original.
Foto de noticias, JPEG, 926×594. Original 131.472 bytes; JPEG optimizado 93.348; WebP 89.360; AVIF 77.452. El mismo tipo de imagen, más pequeña y ya bien comprimida: frente al JPEG, WebP ahorra solo un 4% y AVIF un 17%.
Captura del panel, PNG, 1156×775. Original 105.078 bytes; PNG optimizado (pngquant y optipng) 40.379; WebP 41.218; AVIF 27.942. Los colores planos y el texto son lo que mejor hace un PNG con paleta: WebP salió 839 bytes más pesado que el PNG, mientras que AVIF seguía pesando un 31% menos que él.
Favicon, PNG, 16×16. Original 701 bytes; PNG optimizado 483; WebP 314; AVIF 682. A este tamaño decide el contenedor: 429 de los 682 bytes del AVIF son cajas HEIF que describen la imagen antes de un solo píxel, mientras que el envoltorio del WebP ocupa 46 bytes. AVIF acabó pesando un 41% más que el PNG, y WebP fue el más pequeño.
Lo que se puede extrapolar es el patrón. AVIF gana con claridad en fotografías y capturas detalladas; WebP es una segunda opción segura; en gráficos planos un PNG bien optimizado puede superar a WebP, y en iconos diminutos la carga fija de AVIF pesa más que su mejor compresión. Los bytes exactos dependen del codificador y de su configuración, así que léelos como la medición de un servicio, no como una ley. Ningún porcentaje vale para todas las imágenes: la prueba fiable es codificar la imagen y comparar bytes.
Cómo elige el formato un servidor
Cada petición de imagen lleva una cabecera Accept con los formatos que el navegador puede mostrar. Chrome envía image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8; un navegador sin soporte de AVIF no incluye image/avif. Un servidor o una CDN que convierte imágenes lee esa lista y responde en la misma URL con AVIF, WebP o el original. El nombre del archivo no cambia, así que hero.png puede llegar como AVIF: lo que se envió lo dice la cabecera Content-Type, no la extensión.
Como una URL tiene ahora varias respuestas posibles, la respuesta debe llevar Vary: Accept. Indica a cada caché del camino, desde la CDN hasta un proxy de empresa o el navegador, que guarde una copia distinta por cada valor de Accept. Sin ella, una caché compartida puede entregar el AVIF que recibió un visitante al siguiente, cuyo navegador no sabe mostrarlo.
La otra vía lleva la elección al HTML. Un elemento <picture> enumera archivos <source> con type="image/avif" y type="image/webp", el navegador toma el primer tipo que admite y el <img> interior sirve de alternativa. No necesita lógica en el servidor ni Vary, a cambio de generar y almacenar tú cada variante y mantener el marcado al día. En cualquiera de los dos casos, comprobar qué recibe de verdad un navegador lleva tres peticiones.
Una imagen, tres cabeceras Accept: compara lo que vuelve
# un navegador que acepta AVIF y WebP
curl -so /dev/null -w '%{content_type} %{size_download} bytes\n' \
-H 'Accept: image/avif,image/webp,*/*' https://example.com/hero.png
# un navegador que solo admite WebP
curl -so /dev/null -w '%{content_type} %{size_download} bytes\n' \
-H 'Accept: image/webp,*/*' https://example.com/hero.png
# un cliente que no pide nada en particular
curl -so /dev/null -w '%{content_type} %{size_download} bytes\n' \
-H 'Accept: */*' https://example.com/hero.png
# la cabecera que mantiene honestas a las cachés compartidas (GET, no HEAD)
curl -s -D - -o /dev/null -H 'Accept: image/avif,*/*' \
https://example.com/hero.png | grep -i '^vary'Comprueba qué sirve tu sitio
El comprobador de abajo hace esas peticiones para una página entera. Lee el HTML de la página, toma hasta 20 imágenes de <img>, srcset, <picture> y og:image, y pide cada una dos veces: una como la pide un navegador actual (Accept: image/avif,image/webp,…) y otra como un cliente que acepta cualquier cosa (Accept: */*). Lee los primeros bytes de cada respuesta para saber el formato real, diga lo que diga el nombre del archivo, cuenta los bytes e informa de Vary y del estado de la caché. También puedes introducir la dirección de una sola imagen.
Las peticiones salen de nuestro servidor en Turquía, así que una CDN puede respondernos desde una ubicación distinta a la de tus visitantes. Las imágenes que JavaScript añade después de cargar la página y los fondos CSS no están en el HTML y no se comprueban. La página propia del comprobador detalla todos los límites.
Cómo leer los resultados
AVIF o WebP. Un navegador que pidió formatos modernos recibió uno. El tamaño de al lado es lo que descargó ese navegador; la columna "Otros navegadores" es lo que recibe cualquier navegador sin soporte de AVIF ni WebP. La línea de ahorro suma solo las imágenes cuyas dos respuestas se leyeron completas y llegaron en formatos distintos: es una medición, nunca una estimación.
Solo el original. Incluso un navegador que pidió AVIF y WebP recibió JPEG, PNG o GIF: nada en el camino convierte la imagen. Si unas imágenes llegan en AVIF y otras solo en su formato original, busca qué tiene en común el segundo grupo: otro host, una ruta que ninguna regla cubre, una extensión que el conversor ignora.
El mismo archivo para todos los navegadores. Las dos peticiones recibieron el mismo formato. Es el resultado de un sitio sin negociación, y también el de un sitio que ya sirve archivos .webp a todo el mundo: todos los navegadores actuales los muestran, pero el ahorro adicional de AVIF se queda sin aprovechar. Sin nada que comparar, no se muestra ahorro.
Sin Vary: Accept. La respuesta cambia según Accept pero no lo dice, y las cachés compartidas pueden guardarla. Corrige esto primero: es el único resultado de la lista que puede mostrar a un visitante una imagen rota.
Límite de peticiones o bloqueo. Algunos sitios responden a las peticiones automáticas con un 429, un 403, una comprobación antibots o una pequeña página 503. El comprobador deja entonces de pedir a ese host durante el resto de la comprobación y marca las imágenes restantes como sin comprobar. Eso dice algo de la protección del sitio, no de sus imágenes: vuelve a intentarlo en unos minutos o comprueba directamente la dirección de una imagen.
Una estrategia sensata: AVIF, después WebP, nunca más pesado
Con todo junto, la estrategia que quiere la mayoría de los sitios es corta. Ofrece AVIF primero: en fotografías y capturas detalladas es claramente el más pequeño. Deja WebP como segunda opción para los navegadores sin AVIF. Mantén el original como última alternativa, para que cada navegador reciba una imagen que pueda mostrar.
Luego añade la regla que nos enseñó el favicon: compara bytes imagen por imagen y no envíes nunca un archivo convertido que pese más que el que enviarías de otro modo. El formato es un medio; el objetivo son menos bytes. Un proceso que convierte a ciegas vuelve más pesada una parte de tus imágenes y aun así las da por optimizadas.
Dos notas prácticas. Convierte una vez y guarda el resultado en caché, en el edge de una CDN o en un paso de compilación, en lugar de hacerlo en cada petición: codificar AVIF es la parte cara. Y, cuando puedas, mantén en SVG los logotipos e iconos dibujados en lugar de fotografiados: no hay nada que convertir y se ven nítidos en cualquier pantalla.
AVIF y WebP en CDN.com.tr
La optimización de imágenes es un interruptor del panel, para toda la cuenta o para una sola regla de entrega. Con ella activada, el edge sirve las imágenes JPEG y PNG como WebP a los navegadores que lo admiten; nuestro servicio de imágenes convierte cada imagen una vez y el edge guarda el resultado en caché. Para la cuenta también puedes elegir WebP + AVIF: los navegadores que aceptan AVIF reciben entonces AVIF, los demás navegadores modernos WebP y el resto la imagen en su formato original, todo desde la misma URL, con Vary: Accept y una copia en caché distinta para cada formato.
El procesamiento cuenta para tu cuota mensual, AVIF a una tarifa más alta que WebP porque necesita más CPU; el panel muestra la tarifa junto al interruptor. Ejecuta el comprobador de arriba en tus propias páginas para ver, imagen por imagen, qué formato recibe cada navegador y cuántos bytes ocupa.
Preguntas frecuentes
¿Es AVIF mejor que WebP?
En fotografías e imágenes con detalle, normalmente sí: en nuestra medición AVIF fue el formato más pequeño en las dos fotos de noticias y en la captura del panel. En un favicon de 16 píxeles fue el más grande. "Mejor" es una pregunta por imagen, y por eso un buen proceso ofrece AVIF primero y comprueba los bytes antes de enviarlo.
¿Todos los navegadores admiten AVIF?
Casi todos los actuales. caniuse.com (datos del 30 de septiembre de 2026) sitúa AVIF en torno al 95% de los navegadores en uso y WebP en torno al 97%. Safari anterior a iOS 16, Safari anterior a 16.1 en Mac y Edge anterior a la versión 121 no muestran AVIF, y Safari 16.1 a 16.3 en Mac solo muestra imágenes AVIF estáticas, y solo en macOS 13 Ventura o posterior; con negociación, estos navegadores simplemente reciben WebP o el original.
¿Debo renombrar mis imágenes a .avif?
Solo junto con una alternativa <picture>. Cambiar photo.jpg por photo.avif en tu HTML deja sin imagen a todos los navegadores que no admiten AVIF. Con la negociación en el servidor, la URL no cambia y cada navegador recibe un formato que puede mostrar.
¿Por qué mi WebP pesa más que mi PNG?
Porque el PNG ya es muy bueno con esa imagen. Las capturas, los diagramas y las ilustraciones planas con pocos colores se comprimen extraordinariamente bien como PNG con paleta, y los iconos diminutos dejan poco que ganar a cualquier formato. Nuestra captura del panel salió un 2% más pesada en WebP que en PNG optimizado. Conserva el PNG para esas imágenes; el comprobador de arriba señala aquellas en las que el formato moderno salió más pesado.
¿El comprobador guarda mis imágenes?
No. Lee cada respuesta solo para saber su formato y contar sus bytes; lo que vuelve a tu navegador son formatos, tamaños y unas pocas cabeceras. Una comprobación terminada se reutiliza durante 10 minutos, así que repetirla no envía otra vez las mismas peticiones a tu sitio.