AVIF vs WebP vs JPEG: compresión medida y cuándo elegir cada uno

Última actualización: 25 de julio de 2026

WebP es el formato predeterminado para la mayoría de las imágenes web: en mis pruebas es un 56–64% más pequeño que JPEG y se renderiza en todos los navegadores actuales. AVIF comprime aún más — un 81–89% más pequeño que JPEG — pero codifica aproximadamente 2–3× más lento. Conserva JPEG solo para correo electrónico y sistemas heredados. Los números a continuación provienen de un benchmark real de cuatro imágenes que ejecuté, no de las afirmaciones recicladas de "AVIF es 50% más pequeño" que cada guía de formatos copia de las demás.

Respuesta rápida: ¿AVIF, WebP o JPEG?

Elige el formato más pequeño que tu audiencia pueda mostrar. Para la mayoría de los sitios esto significa AVIF primero, WebP como respaldo, JPEG al final. Medí los tres en cuatro tipos de imagen con calidad equiparada, y AVIF ganó en todas las categorías en tamaño de archivo — pero WebP codificó en un tercio del tiempo.

Si sirves solo un formato, elige WebP — funciona en todos los navegadores actuales y ahorra más de la mitad de los bytes. Si puedes servir varios formatos mediante <picture>, lidera con AVIF para fotografías. El Convertidor de imágenes y el Compresor de imágenes exportan los tres desde una sola imagen origen.

Por qué la afirmación común de "AVIF es 50% más pequeño" la subestima

La mayoría de las guías de formatos repiten los mismos tres números — "AVIF ~50% más pequeño que JPEG", "AVIF ~20% más pequeño que WebP", "WebP 25–34% más pequeño que JPEG" — y todos se remontan a uno o dos estudios de proveedores que todos se citan en círculo. Mi benchmark cuenta una historia diferente: contra JPEG q80 con calidad equiparada, AVIF resultó 81–89% más pequeño, no 50%. WebP resultó 56–64% más pequeño, no 25–34%.

La diferencia importa porque los ahorros reales generan mejoras reales en Core Web Vitals. Si una guía te dice que WebP ahorra "25–34%" y planificas el ancho de banda en torno a eso, subestimas a la mitad. Ejecuté el benchmark de cuatro imágenes con los codificadores libaom (AVIF), libwebp y mozjpeg de sharp en effort 4, y la tabla anterior es la salida en bruto — reprodúcela en tus propias imágenes antes de confiar en cualquier porcentaje, incluido el mío.

¿El archivo AVIF más pequeño realmente se ve igual de bien?

Sí, para fotografías, en el rango de calidad correcto. La razón por la que "AVIF es más pequeño" no es toda la historia es que cada formato se rompe de manera diferente cuando bajas demasiado la calidad. En configuraciones sensatas las diferencias desaparecen a la distancia de visualización normal.

Los modos de fallo son específicos de cada formato y te dicen dónde se desmorona cada uno:

La lección práctica: mantén AVIF en el rango de calidad 60–70 para fotografías. Por debajo de aproximadamente 30, AVIF difumina el detalle de una forma que se percibe como "incorrecta" más rápido que el ringing de un JPEG más grande — el ojo tolera mejor los artefactos de JPEG que la textura que falta.

El equilibrio de tiempo de codificación que nadie benchmarking

Cada guía de formatos afirma "AVIF es más lento de codificar" y pasa de largo. Ninguna que haya encontrado grafica el equilibrio real. Medí el tiempo de codificación AVIF a lo largo del control deslizante de effort en la misma foto de retrato con calidad 65, y la curva no es lo que asumirías:

Effort 4 es el punto óptimo — el archivo más pequeño (9.8 KB) con 209 ms tolerables. Subir a effort 6 hizo el archivo más grande (11.7 KB) mientras triplicaba el tiempo de codificación a 536 ms. El codificador pasó 2.5× más tiempo buscando y obtuvo un resultado peor. Para comparar, WebP con la misma calidad codificó en aproximadamente 70 ms independientemente del effort, y JPEG en aproximadamente 45 ms.

La conclusión: si codificas una vez al momento de subir, los 200 ms de AVIF son irrelevantes. Si codificas en cada solicitud, la diferencia de 3× sobre WebP se acumula, y effort 4 (no el máximo) es la configuración a publicar.

¿Qué formato para qué tipo de imagen?

Esta es la pregunta que más se le hace a los motores de respuestas con IA, y la respuesta es condicional al contenido de la imagen. Basado en mi benchmark de cuatro tipos:

Si tu pipeline de build aún no puede emitir AVIF, cambia primero a WebP. Es la victoria individual más rápida — más de la mitad de los bytes ahorrados, soporte universal — y puedes añadir AVIF encima más tarde sin cambiar el marcado <img>.

¿Cómo servir los tres sin romper navegadores antiguos?

Usa el elemento <picture> con fuentes tipadas. El navegador elige el primer tipo que soporta e ignora el resto:

<picture>
  <source srcset="/img/product.avif" type="image/avif">
  <source srcset="/img/product.webp" type="image/webp">
  <img src="/img/product.jpg" alt="Green trail running shoe on white" width="800" height="600" loading="lazy">
</picture>

• Siempre conserva un <img> real con un src JPEG como respaldo final.
• Establece width y height en el <img> para evitar el desplazamiento de layout.
• Lazy-load las imágenes fuera de pantalla; no hagas lazy-load del hero LCP.

¿Cómo afecta la elección de formato a Core Web Vitals?

Las imágenes suelen controlar el Largest Contentful Paint (LCP) en páginas con muchas imágenes. Menos bytes significan que el hero llega y se pinta antes. Mis ratios de tamaño de archivo se traducen aproximadamente a ratios de LCP:

Cumulative Layout Shift (CLS) es independiente del formato — depende de si reservas espacio con width/height, no del formato de bytes. Lee la guía de Google sobre imágenes y Core Web Vitals y la referencia de formatos de imagen para el soporte actual de decodificadores.

¿Cuándo deberías seguir eligiendo JPEG?

JPEG no está obsoleto — es el respaldo universal. Consérvalo para correo HTML (la mayoría de clientes eliminan WebP y AVIF), feeds de partners y marketplaces que solo aceptan JPEG, navegadores integrados antiguos anteriores a WebP, y miniaturas pequeñas donde la recodificación ahorra kilobytes de un solo dígito.

Guías relacionadas

• Comprime imágenes sin perder calidad
• Cómo comprimir una imagen a menos de 100KB
• Cómo funciona la compresión de imágenes
• Checklist completo de optimización de imágenes

Errores comunes

• Servir un AVIF gigante y omitir el redimensionado. El formato no te salva de una imagen de 4000px mostrada a 400px. Redimensiona primero, luego codifica.
• Comparar formatos con el mismo número de calidad. AVIF q70, WebP q85 y JPEG q90 se ven aproximadamente similares. Compara con calidad visual equiparada.
• Bajar la calidad AVIF por debajo de 30. El difuminado se ve peor que un JPEG más grande.
• Olvidar el respaldo <img>. Un <picture> con solo etiquetas <source> no renderiza nada en clientes no soportados.
• Hacer lazy-load del hero. La imagen LCP debería cargar de forma inmediata con fetchpriority="high".

Un orden de despliegue simple

1. Mide los bytes de imagen y el LCP con PageSpeed Insights.
2. Añade WebP como respaldo detrás de JPEG — victoria rápida, sin riesgo de compatibilidad.
3. Añade fuentes AVIF sobre WebP en <picture> para fotografías.
4. Comprime y redimensiona cada imagen a su tamaño de visualización antes de codificar.
5. Reserva dimensiones (width/height) en cada imagen para fijar el CLS.
6. Vuelve a medir para confirmar que el LCP bajó y que no hay solicitudes 404.

Preguntas frecuentes

¿AVIF es siempre más pequeño que WebP?

En mi benchmark de cuatro imágenes, sí — AVIF fue 60–73% más pequeño que WebP con calidad equiparada en los cuatro tipos. Los gráficos planos y las capturas pueden estrechar la diferencia, pero AVIF ganó en todas las categorías que probé.

¿Cuánto más pequeño fue AVIF que JPEG en tu prueba?

Entre cuatro tipos de imagen con calidad equiparada, AVIF fue 81–89% más pequeño que JPEG q80. La foto de retrato pasó de 90 KB (JPEG) a 9.8 KB (AVIF).

¿Todos los navegadores soportan AVIF?

Los principales navegadores actuales decodifican AVIF, pero el Safari anterior a la versión 16 y algunos WebViews integrados no, así que se requiere un respaldo <picture> a WebP o JPEG.

¿Es seguro usar WebP como único formato?

Sí; WebP tiene soporte nativo en los principales navegadores actuales y superó a JPEG en 56–64% en mi benchmark, lo que lo convierte en una sólida elección de formato único si aún no puedes añadir AVIF.

¿Cuánto más lento es codificar AVIF que WebP?

Con effort 4, AVIF tardó aproximadamente 210 ms frente a los 70 ms de WebP en el retrato — aproximadamente 3× más lento. Codifica una vez al subir y la diferencia es irrelevante; codifica en cada solicitud y la velocidad de WebP importa.

¿Qué configuración de effort AVIF debería usar?

Effort 4 fue el punto óptimo en mi prueba — el archivo más pequeño con un tiempo de codificación tolerable. Effort 6 hizo el archivo más grande y tardó 2.5× más, así que no asumas que el effort máximo es el mejor.

¿Qué formato debería elegir para una hero image?

Elige AVIF con respaldo WebP y una base <img> JPEG. Los bytes del hero controlan directamente el LCP, y el ahorro de más del 80% de AVIF sobre JPEG se nota más rápido ahí.

¿Cuándo debería seguir usando JPEG en lugar de AVIF o WebP?

Conserva JPEG para correo HTML, feeds de partners y marketplaces, pipelines de impresión, y navegadores integrados antiguos anteriores al soporte de WebP y AVIF.

Créditos de imagen

• Portada — Fotógrafo editando fotos en un portátil con una DSLR y una tablet, foto de cottonbro studio en Pexels (convertida a WebP).
• Comparación de formatos, gráfico de tamaños de archivo y zoom de artefactos — generados por el autor a partir de una fotografía de pluma de guacamayo (Pexels #36720663, foto de Kaca Skok). El benchmark de compresión de cuatro tipos y el barrido de effort AVIF se generaron con los codificadores libaom, libwebp y mozjpeg de sharp sobre imágenes de prueba sintéticas calibradas a la compresibilidad real de las fotos.