WebP vs AVIF: La guerra de los formatos de imagen modernos

WebP y AVIF son formatos de imagen modernos diseñados para reemplazar a JPG en la entrega web. Ambos logran tamaños de archivo significativamente más pequeños con una calidad equivalente. Ambos tienen amplia compatibilidad con navegadores en 2026. Ambos cuentan con herramientas de CDN. Y ambos tienen desventajas que importan en producción. Después de ejecutar conversiones reales en un conjunto de prueba de 500 imágenes, que incluye contenido fotográfico, ilustraciones y capturas de pantalla, aquí tienes la comparación honesta y la recomendación lista para producción.

Si eres desarrollador web, ingeniero de rendimiento o responsable de comercio electrónico decidiendo qué formato implementar en 2026, esta es la guía práctica. Cubre resultados de compresión, compatibilidad con navegadores, costo de codificación, integración con CDN y los patrones de producción que realmente escalan.

Antecedentes y contexto

WebP fue desarrollado por Google a partir de 2010, basado en el códec de video VP8. Fue promovido agresivamente a través de Chrome y las herramientas web de Google, y alcanzó compatibilidad mayoritaria con navegadores alrededor de 2018. AVIF fue desarrollado por Alliance for Open Media, el mismo grupo detrás del códec de video AV1, y alcanzó compatibilidad de producción en navegadores a partir de 2020. Ambos formatos representan una mejora generacional sobre JPG en eficiencia de compresión, y ambos se consideran ahora expectativas básicas para la entrega web consciente del rendimiento.

Los resultados de compresión

En un conjunto de prueba de 500 imágenes — 60 por ciento fotografías, 25 por ciento ilustraciones y activos de interfaz, 15 por ciento capturas de pantalla — convertidas desde archivos fuente JPG de calidad 90 con calidad perceptual equivalente:

• JPG (referencia): promedio de 412 KB por imagen
• WebP (calidad 80): promedio de 268 KB por imagen — 35 por ciento más pequeño
• AVIF (calidad 65): promedio de 178 KB por imagen — 57 por ciento más pequeño

AVIF gana en eficiencia de compresión bruta por aproximadamente 30 por ciento sobre WebP. La brecha es mayor en contenido fotográfico y menor en gráficos sintéticos. La ventaja de AVIF es más pronunciada en degradados suaves y tonos de piel, donde conserva detalles en tamaños de archivo que WebP no puede igualar.

Comparación de formatos

Atributo	JPG	WebP	AVIF
Tamaño promedio de archivo (prueba de 500 imágenes)	412 KB	268 KB	178 KB
Compresión vs JPG	referencia	-35%	-57%
Soporte del navegador 2026	100%	99.7%	~96%
Velocidad de codificación	Rápida	Media	Lenta (8-20x WebP)
Velocidad de decodificación	Rápida	Rápida	Media
Modo sin pérdida	No	Sí	Sí
Alfa (transparencia)	No	Sí	Sí
Animación	No	Sí	Sí
Soporte HDR	No	Limitada	Sí (10/12 bits)

Compatibilidad con navegadores en 2026

WebP es universal. Chrome, Firefox, Safari, Edge, Opera y todos los navegadores móviles lo han soportado durante años. Las versiones antiguas de Safari en iOS 13 y anteriores no lo hacen, pero esa base de usuarios está por debajo del 0.3 por ciento a nivel global.

El soporte de AVIF ahora es amplio pero no universal. Chrome y Firefox soportan AVIF desde 2020. Safari agregó soporte en iOS 16 (septiembre de 2022). Edge lo soporta. Opera lo soporta. La brecha combinada son versiones antiguas de Safari en macOS, algunos navegadores integrados y un puñado de navegadores dentro de aplicaciones (principalmente versiones antiguas de las vistas web integradas de Facebook y LinkedIn). El número correcto para sitios de producción en 2026 es aproximadamente 96 por ciento de soporte global de AVIF.

La mayoría de los sitios de producción sirven AVIF con respaldos de WebP y JPG mediante el elemento HTML picture. El CDN o framework maneja la negociación de forma transparente.

Velocidad de codificación y costo de CPU

Aquí es donde la ventaja de AVIF se complica. La codificación AVIF es significativamente más lenta que la codificación WebP — aproximadamente de 8 a 20 veces más lenta en configuraciones predeterminadas. Una codificación WebP de una foto de 12 megapíxeles en hardware moderno toma de 200 a 400 milisegundos. La misma imagen a AVIF toma de 3 a 8 segundos en la configuración de velocidad predeterminada del codificador, o de 15 a 30 segundos en configuraciones lentas pero de mejor calidad.

Para un sitio estático con un paso de compilación, el tiempo de codificación se paga una vez y los ahorros se acumulan para siempre — sin discusión, AVIF gana. Para un sitio con subidas de usuarios donde las imágenes se procesan en tiempo real (un mercado, una plataforma social, un CMS), el costo de codificación importa. Muchos sitios usan WebP para subidas de usuarios y AVIF solo para imágenes principales y contenido editorial.

Velocidad de decodificación

WebP decodifica ligeramente más rápido que AVIF en la mayoría de los dispositivos, pero ambos son lo suficientemente rápidos en hardware moderno como para que la diferencia sea invisible para los usuarios. En dispositivos Android de gama baja y hardware iOS antiguo, la decodificación AVIF puede introducir un retraso notable en páginas con muchas imágenes — menos de 100 milisegundos por imagen, pero acumulativo en un feed largo.

Herramientas de CDN

Cloudflare Images, Cloudinary, Imgix, AWS CloudFront con Lambda@Edge, el optimizador de imágenes de Vercel, Next.js Image y la mayoría de los CMS modernos soportan la entrega automática de AVIF y WebP con respaldo de JPG. La negociación se basa en el encabezado Accept del navegador. Subes un archivo fuente — generalmente JPG o PNG — y el CDN sirve AVIF a los navegadores que lo aceptan, WebP a los que aceptan eso y JPG a todos los demás.

Esta es la arquitectura lista para producción en 2026. Casi nunca querrás gestionar tres conjuntos de archivos manualmente.

Guía paso a paso: implementando AVIF + WebP + JPG

1. Audita las imágenes actuales. Identifica las fuentes JPG y PNG que quieres optimizar.
2. Decide entre tiempo de compilación o tiempo de ejecución. Sitios estáticos: tiempo de compilación. Sitios dinámicos: tiempo de ejecución del CDN.
3. Para tiempo de compilación, ejecuta los codificadores AVIF y WebP. Genera tres versiones de cada imagen.
4. Configura tu HTML. Usa el elemento picture con un fallback basado en tipo.
5. Define objetivos de calidad. AVIF q65, WebP q80, JPG q85 — calidad perceptual equivalente.
6. Prueba en navegadores representativos. Chrome (AVIF), Safari iOS 15 (WebP), Safari antiguo (JPG).
7. Mide los Core Web Vitals. El LCP debería mejorar notablemente con el despliegue de AVIF.
8. Configura una caché de compilación. Evita recodificar imágenes sin cambios en cada compilación.

Cuándo elegir cada uno

Elige WebP cuando necesites compatibilidad universal sin fallbacks, cuando la velocidad de codificación importe (subidas de usuarios, procesos en tiempo real), cuando tu CDN no soporte AVIF, o cuando tu audiencia use dispositivos antiguos. WebP es la opción segura por defecto. Convierte archivos JPG maestros con el convertidor de JPG a WebP para archivos individuales o en lote.

Elige AVIF cuando el tamaño del archivo sea la prioridad, puedas asumir el costo de codificación (sitio estático, conversión en compilación), tu CDN maneje fallbacks, y tu audiencia use dispositivos modernos. AVIF gana en Core Web Vitals — sus tamaños de archivo más pequeños mejoran directamente el Largest Contentful Paint y el tamaño total de transferencia. Convierte con el convertidor de JPG a AVIF.

Elige ambos para cualquier sitio de producción serio. AVIF como formato principal, WebP como fallback para navegadores que no soporten AVIF, y JPG como fallback universal. El elemento picture maneja la negociación.

El patrón HTML

El patrón estándar es así:

• source type="image/avif" srcset="image.avif"
• source type="image/webp" srcset="image.webp"
• img src="image.jpg" alt="..."

Envuelto en un elemento picture. El navegador elige el primer formato que soporte. Sin JavaScript, sin negociación de cabecera Accept, sin dependencia del CDN.

Ejemplos reales

Acme Tools, una tienda de comercio electrónico. Migró 12,000 imágenes de producto de JPG a AVIF+WebP+JPG mediante Cloudflare Images. El peso de la página se redujo un 48 por ciento. El Largest Contentful Paint mejoró 1.2 segundos en móvil. La tasa de conversión subió un 8 por ciento.

El blog The Mountaineer. Sitio Hugo estático con 800 imágenes principales. Codificación AVIF y WebP en tiempo de compilación con cwebp y cavif. El tiempo de compilación pasó de 90 segundos a 14 minutos, pero la factura de ancho de banda bajó un 60 por ciento y los Core Web Vitals pasaron de amarillo a verde en todas las páginas.

FlatField marketplace. Sitio con muchas subidas de usuarios. Usó solo WebP para las subidas de usuarios (el costo de codificación en tiempo real importaba) y AVIF para los encabezados de categorías estáticos y los activos de marca. El enfoque híbrido ahorró un 35 por ciento de ancho de banda sin ralentizar los procesos de subida.

¿Y volver a JPG?

A veces tienes archivos WebP o AVIF y necesitas convertirlos de vuelta a JPG — para una herramienta que no acepta formatos modernos, para un laboratorio de impresión, para un portal de seguros. El convertidor de WebP a JPG y el convertidor de AVIF a JPG manejan estas conversiones directas. Ten en cuenta que ambas direcciones son con pérdida si partes de una fuente con pérdida — no hay forma de recuperar el detalle que el codificador original de WebP o AVIF descartó.

Errores comunes y cómo evitarlos

• Codificar AVIF con la configuración de velocidad por defecto en un sitio estático. Pierde importantes ganancias de calidad. Solución: usa ajustes de velocidad más lentos (cavif --speed 4) para la codificación en compilación.
• Comparar tamaños de archivo con el mismo número de calidad. WebP q80 y AVIF q80 son diferentes. Solución: iguala la calidad perceptual con una comparación lado a lado.
• Desplegar AVIF sin un fallback a WebP. Algunos navegadores aún necesitan WebP. Solución: incluye siempre WebP en el elemento picture.
• Intentar usar AVIF para procesos de subida de usuarios en tiempo real. El costo de codificación satura el servidor. Solución: WebP para subidas, AVIF para contenido editorial.
• No probar en Safari iOS. Las versiones antiguas carecen de soporte AVIF. Solución: verifica en iOS 15 y versiones anteriores.
• Olvidar el fallback a JPG. Los navegadores integrados y las vistas web en aplicaciones fallan. Solución: incluye siempre el img src JPG.

Consejos avanzados

• Usa libvips o sharp en Node.js para codificación rápida por lote entre formatos.
• Crea una clave de caché basada en el hash de la fuente + el ajuste de calidad para evitar recodificar.
• Para las imágenes principales, codifica en múltiples resoluciones (srcset) para una entrega responsive.
• Prueba la calidad perceptual con SSIMULACRA2 o DSSIM en lugar de hacerlo a ojo.
• Para contenido animado, AVIF y WebP superan a GIF — convierte con el convertidor de GIF a JPG para fotogramas estáticos o usa APNG/AVIF directamente.
• Para la optimización de Lighthouse y Core Web Vitals, AVIF en la imagen LCP produce el mayor impacto.
• Para el máximo ahorro de ancho de banda, combina AVIF con HTTP/3 y compresión Brotli en el HTML.

Preguntas frecuentes

¿Reemplazará AVIF a JPG por completo?

No pronto. JPG sigue siendo la lengua franca universal para el intercambio de imágenes. AVIF es una optimización de entrega.

¿Qué hay de JPEG XL?

Prometedor pero con soporte limitado en navegadores. Chrome eliminó el soporte en 2022; Safari tiene soporte experimental. No está listo para producción en 2026.

¿AVIF soporta animación?

Sí — AVIF se basa en AV1, que soporta video. AVIF animado funciona en navegadores modernos.

¿Es útil el modo sin pérdida de WebP?

Sí, para capturas de pantalla, activos de interfaz de usuario e imágenes sintéticas. Para fotografías, WebP con pérdida es la mejor opción.

¿Puedo editar AVIF y WebP directamente?

La mayoría de los editores modernos son compatibles con ambos. Photoshop añadió AVIF en 2022. GIMP y Affinity Photo también son compatibles con ambos.

¿El ahorro de datos móviles es mayor con AVIF?

Sí: los archivos más pequeños significan menos tiempo de radio, lo que afecta directamente a la batería y los datos móviles.

¿Y el costo del lado del servidor?

La codificación AVIF consume mucha CPU. Los sitios estáticos pagan una vez al compilar. Los servicios CDN dinámicos lo amortizan entre todos los visitantes.

El veredicto de 2026

WebP es el valor predeterminado seguro para producción. AVIF es el techo de rendimiento. La mayoría de los sitios serios deberían servir AVIF como principal, WebP como respaldo y JPG como respaldo universal. Convierte tus fuentes una vez con el convertidor de JPG a WebP y el convertidor de JPG a AVIF. Si el tamaño del archivo importa más que la velocidad de codificación, inclínate por AVIF. Si la velocidad de codificación importa más, inclínate por WebP. Si tienes un sitio estático con un paso de compilación, haz ambos: el costo se paga una vez y el ahorro de ancho de banda se acumula para cada visitante durante toda la vida del sitio.

Para todo lo que aún necesita una salida JPG (impresión, archivos adjuntos de correo electrónico, sistemas heredados), mantén el compresor JPG en el flujo de trabajo. JPG no va a desaparecer. Simplemente ya no es el formato adecuado para la página principal de un sitio web rápido.

Por qué JPEG XL no ganó

JPEG XL se desarrolló como un sucesor designado del JPG clásico, con mejor compresión, recodificación sin pérdida desde JPG existentes y soporte de funciones más amplio. Chrome añadió soporte experimental, luego lo eliminó en 2022, citando una adopción insuficiente. Safari tiene soporte experimental detrás de una bandera. Firefox no se ha comprometido.

La razón por la que JPEG XL no ganó es en gran medida estratégica: el interés de Google en WebP y el ecosistema AV1 (que subyace a AVIF) significó que Chrome tenía menos incentivos para promover un formato competidor. Sin soporte de Chrome, la adopción web quedó efectivamente bloqueada. JPEG XL sigue siendo técnicamente excelente pero prácticamente marginal.

La economía de la adopción de formatos

Cada transición de formato cuesta ancho de banda, cómputo de codificación y esfuerzo de ingeniería por adelantado, y ahorra ancho de banda a perpetuidad. Las matemáticas: un sitio que sirve 10 millones de vistas de imagen al mes con un promedio de 400 KB en JPG está moviendo 4 TB al mes. Cambiar a AVIF con un promedio de 175 KB ahorra 2.25 TB al mes, aproximadamente $200 a $400 en costos de ancho de banda de CDN según el proveedor.

Para sitios de alto tráfico, la migración a AVIF se amortiza en meses. Para sitios de bajo tráfico, el esfuerzo de ingeniería puede superar el ahorro. El punto de equilibrio es aproximadamente 50,000 vistas de imagen al mes; por debajo de eso, está bien quedarse con JPG optimizado.

Calibración de calidad entre formatos

Los ajustes de calidad no son portables entre formatos. La calidad 85 de JPG no equivale a la calidad 85 de WebP ni a la calidad 85 de AVIF. Cada códec usa una cuantización interna diferente, por lo que los números representan cosas distintas.

La forma correcta de comparar es perceptual: producir salidas que se vean iguales al ojo (o a una métrica objetiva como SSIMULACRA2 o DSSIM), luego comparar tamaños de archivo. Los números en la introducción (JPG q90, WebP q80, AVIF q65) provienen de este tipo de ejercicio de coincidencia en un conjunto de prueba de 500 imágenes.

Consideraciones del modo sin pérdida

Tanto WebP como AVIF son compatibles con el modo de compresión sin pérdida. WebP sin pérdida suele superar a PNG entre un 20 y un 25 por ciento en el mismo contenido. AVIF sin pérdida es aproximadamente comparable a WebP sin pérdida, a veces ligeramente mejor. Para activos de interfaz de usuario, capturas de pantalla, ilustraciones con bordes nítidos y cualquier contenido donde la compresión sin pérdida importe, ambos formatos son excelentes reemplazos de PNG.

JPG no tiene modo sin pérdida en el uso estándar. JPEG XL tiene modo sin pérdida y puede recodificar sin pérdida JPG existentes en tamaños de archivo más pequeños, pero el soporte del navegador es limitado.

HDR y gama de colores amplia

AVIF es compatible con profundidad de color de 10 y 12 bits y funciones de transferencia HDR de forma nativa. WebP solo es compatible con 8 bits. Para contenido HDR (la pequeña pero creciente proporción de fotos capturadas con teléfono con metadatos HDR), AVIF preserva el HDR; WebP lo colapsa a SDR.

Esto importa cada vez más para el contenido capturado con iPhone. iOS 15+ captura fotos HDR de forma predeterminada, y las pantallas modernas (iPhone 12 Pro+, MacBook Pro recientes, iPads recientes) pueden mostrarlas. La entrega AVIF preserva la experiencia HDR; JPG y WebP no.

Licencias de códec

WebP es libre de regalías bajo la licencia abierta de Google. AVIF es libre de regalías bajo la licencia de Alliance for Open Media. Ambos se pueden usar en productos comerciales sin pago. JPEG XL también es libre de regalías.

Esto es parte de por qué AVIF ganó adopción más rápido que su predecesor HEIC (que tiene enredos de patentes y regalías). El estado libre de regalías eliminó una barrera importante para la adopción.

Opciones de codificador del lado del servidor

Codificador	Formato	Velocidad	Calidad por defecto
libwebp / cwebp	WebP	Rápida	Buena
libavif / cavif	AVIF	Media	Excelente
libaom (referencia)	AVIF	Lento	Mejor
rav1e	AVIF	Más rápido que libaom	Muy buena
SVT-AV1	AVIF	Rápido (multihilo)	Muy buena
libjpeg-turbo	JPG	Muy rápido	Bueno (línea base)
mozjpeg	JPG	Rápida	Mejor que libjpeg-turbo

Para obtener la máxima calidad AVIF a una velocidad aceptable en 2026, SVT-AV1 es la opción práctica para la codificación por lotes de sitios estáticos. libaom es la opción lenta pero mejor para imágenes de máxima importancia.

SEO y posicionamiento en buscadores

Google considera el formato de imagen y el tamaño del archivo como parte de la puntuación de Core Web Vitals, lo que influye en el posicionamiento en buscadores. Los sitios que implementan AVIF (o WebP) y logran un Largest Contentful Paint en menos de 2.5 segundos se posicionan mejor que los sitios equivalentes solo con JPG. El efecto es pequeño por página, pero se acumula en miles de páginas indexadas.

PageSpeed Insights de Google marca explícitamente "Servir imágenes en formatos de nueva generación" como una recomendación. Los sitios que aún solo sirven JPG reciben esta advertencia. Los sitios que sirven AVIF con respaldo WebP la superan sin problemas.

Preparar tu implementación para el futuro

El patrón del elemento picture de HTML es compatible con el futuro. Cuando surja el próximo formato (probablemente JPEG XL, o algún otro contendiente), puedes agregar una nueva línea de origen encima del origen AVIF sin afectar a los navegadores existentes. El patrón de negociación de formato es la elección arquitectónica correcta, independientemente de qué formatos ganen.

Si empiezas desde cero hoy, construye el patrón del elemento picture desde el primer día. Incluso si solo tienes fuentes JPG, el patrón de envoltura significa que las futuras adiciones de formato serán una simple actualización de plantilla.

Herramientas relacionadas: Convertidor de WebP a JPG, Convertidor de AVIF a JPG, convertidor universal de imágenes, compresor universal de imágenes, Convertidor de JPG a WebP, Convertidor de JPG a AVIF.