WebP vs AVIF en 2026: Cuál Usar en tu Web
Comparativa honesta 2026: WebP vs AVIF para rendimiento web, soporte navegador, peso, velocidad de codificación y la cadena de fallback práctica, con benchmarks reales.
WebP salió en 2010. AVIF salió en 2019. En 2026, ambos son maduros, ambos tienen ~94%+ de soporte global, y ambos aplastan a JPG/PNG en peso. Pero elegir entre ellos, o cómo usar ambos, sigue confundiendo a desarrolladores y gestores de contenido. Esta guía da benchmarks reales y una regla limpia.
TL;DR, la respuesta 2026
Para sitios estáticos y assets pre-construidos: AVIF primero, WebP fallback, JPG/PNG último. La etiqueta <picture> gestiona la cadena automáticamente.
<picture>
<source srcset="/img/foto.avif" type="image/avif" />
<source srcset="/img/foto.webp" type="image/webp" />
<img src="/img/foto.jpg" alt="…" />
</picture>Para redimensionado dinámico, generación en tiempo real o presupuestos de CPU limitados: solo WebP. La codificación AVIF es demasiado pesada para hacer en cada petición.
La decisión en una frase
Si la imagen se genera una vez y se sirve por siempre, usa AVIF + WebP fallback. Si se genera por petición, solo WebP.
Benchmarks reales: misma fuente, ambos formatos
10 fotos representativas comprimidas a calidad “visualmente sin pérdida” (SSIM ≥ 0,99 vs original):
| Fuente (4000×3000 JPG) | JPG q90 | WebP q80 | AVIF q60 | AVIF vs JPG |
|---|---|---|---|---|
| Foto playa (gradiente cielo) | 2,4 MB | 1,3 MB | 0,7 MB | −71% |
| Retrato (tonos piel) | 1,8 MB | 0,9 MB | 0,55 MB | −69% |
| Producto en fondo blanco | 1,1 MB | 0,45 MB | 0,28 MB | −75% |
| Paisaje urbano (mucho detalle) | 3,2 MB | 1,8 MB | 1,1 MB | −66% |
| Fotografía de comida | 2,1 MB | 1,0 MB | 0,62 MB | −70% |
| Paisaje con textura | 2,7 MB | 1,6 MB | 1,0 MB | −63% |
| Logo / ilustración | 380 KB | 120 KB | 95 KB | −75% |
| Captura de pantalla (UI) | 540 KB | 210 KB | 165 KB | −69% |
| Moda (alto contraste) | 1,9 MB | 0,95 MB | 0,58 MB | −69% |
| Macro / detalle natural | 2,5 MB | 1,4 MB | 0,85 MB | −66% |
| Promedio | 1,86 MB | 0,97 MB | 0,61 MB | −70% |
Para una imagen típica, AVIF ahorra ~70% sobre JPG, ~37% sobre WebP. El ahorro es masivo a escala: 100 fotos = 130 MB JPG, 60 MB WebP, 36 MB AVIF.
Realidad del soporte de navegador
| Navegador | WebP | AVIF | Cuota mercado (2026) |
|---|---|---|---|
| Chrome (escritorio + Android) | 2014+ | Ago 2020+ | 65% |
| Edge | 2018+ | 2021+ | 5% |
| Firefox | 2019+ | Oct 2021+ | 3% |
| Safari (iOS + macOS) | 2020 (14+) | Mar 2022 (16+) | 19% |
| Samsung Internet | 2019+ | 2021+ | 3% |
| Opera | 2014+ | 2020+ | 2% |
| IE antiguo / IE Mode | Nunca | Nunca | <1% |
| Soporte combinado | ~99% | ~94% | n/a |
El 6% sin AVIF
El 6% sin AVIF son: (a) Android < 7 todavía en uso en algunas regiones, (b) rezagos corporativos de Edge/IE, (c) WebViews embebidos en apps antiguas. Siempre envía un fallback WebP, los cubre a todos.
Velocidad de codificación: la ventaja WebP
La compresión AVIF es más pesada porque el códec es más complejo (derivado de HEVC). En una carga típica:
| Operación | WebP (libwebp) | AVIF (libaom) | Diferencia |
|---|---|---|---|
| Foto 4 MP → q80 | 0,8s | 4,2s | 5× más lento |
| Foto 4 MP → q60 | 0,6s | 3,5s | 5,8× más lento |
| Foto 12 MP → q80 | 2,1s | 12s | 5,7× más lento |
| 100 miniaturas (300×300) | 8s | 38s | 4,7× más lento |
| Build biblioteca completa (1000 imgs) | 14 min | 1h 12min | 5,1× más lento |
Para builds de sitios estáticos esto está bien, codificas una vez, sirves por siempre. Para redimensionado dinámico (ej. usuarios suben avatars en tiempo de petición), el coste 5× es prohibitivo.
Cuándo elegir WebP
Solo WebP cuando
- Generas imágenes en tiempo de petición
- El presupuesto CPU/tiempo de build es limitado
- Quieres tooling más simple (más librerías)
- Tu CDN aún no soporta AVIF
- Tu audiencia tiene Android muy antiguo
AVIF + WebP fallback cuando
- Sitio estático con assets pre-construidos
- Sitio con muchas fotos (e-commerce, porfolio, news)
- El coste de ancho de banda importa (CDN, móvil)
- Core Web Vitals son críticos
- Puedes permitirte CPU en build-time
La cadena de fallback en la práctica
El elemento HTML <picture> es la forma estándar de enviar múltiples formatos. El navegador elige el primero que entiende.
<picture>
<source type="image/avif" srcset="/img/hero.avif" />
<source type="image/webp" srcset="/img/hero.webp" />
<img src="/img/hero.jpg" alt="Imagen hero" loading="lazy" />
</picture>Los frameworks modernos lo generan automáticamente:
| Framework | Cómo |
|---|---|
| Astro | <Image src=... formats={['avif', 'webp']} /> |
| Next.js | next/image + config images.formats |
| Gatsby | gatsby-plugin-image con formats |
| Vite | Plugin vite-imagetools |
| Nuxt | @nuxt/image con array format |
| Hugo | Page resources + Resize + Convert |
No envíes AVIF sin WebP
El 6% de usuarios sin soporte AVIF no ven una "imagen rota", no ven nada. La etiqueta <picture> cae al <img> si todos los <source> fallan. Incluye siempre WebP (o JPG) como red de seguridad.
Mapeo de calidad
El número que pones en q= para AVIF no mapea a JPG/WebP. Equivalencias aproximadas:
| Calidad visual | JPG q | WebP q | AVIF q |
|---|---|---|---|
| Casi sin pérdida | 95 | 95 | 80 |
| Visualmente sin pérdida | 90 | 85 | 65 |
| Nítido a vista normal | 85 | 80 | 60 |
| Aceptable | 75 | 70 | 50 |
| Compresión visible | 60 | 55 | 35 |
| Artefactos fuertes | 40 | 35 | 20 |
Default para web: JPG 85, WebP 80, AVIF 60, todos producen output visualmente idéntico.
Tips de codificación
- Codifica siempre desde el original (no desde un JPG → re-codificado a WebP), o acumulas pérdidas.
- Para fotos, usa q60 AVIF / q80 WebP, el sweet spot.
- Para gráficos con bordes nítidos, cambia a WebP lossless o PNG fallback. AVIF lossy puede difuminar líneas finas.
- No te molestes con AVIF para miniaturas bajo 100×100, la diferencia es mínima vs el coste de codificación.
- Quita metadatos (EXIF, ICC) cuando puedas, ahorra otros 10–30 KB por imagen.
¿Y JPEG XL?
JPEG XL (JXL) es un formato más nuevo que algunos llamaron “AVIF killer” en 2022. En 2026:
- Chrome quitó el soporte en 2023 (decisión polémica).
- Safari sí lo soporta (desde iOS 17).
- Firefox: detrás de flag.
No vale la pena desplegar en producción aún. La historia de soporte navegador es demasiado incierta. Revisa en 2027.
Resumen
Para el 90% de webs en 2026:
- El pipeline de build codifica cada imagen a AVIF + WebP + JPG/PNG.
<picture>en HTML sirve la correcta según el navegador.- JPG calidad 85, WebP 80, AVIF 60 como defaults, visualmente idénticos.
- Salta AVIF solo para imágenes diminutas o paths de generación dinámica.
- Mide con Core Web Vitals antes y después, el peso de imagen debería bajar ~70%.
Puedes convertir tus assets existentes ahora mismo con JPG a WebP, PNG a WebP, o por lotes vía Convertir Imagen. Todo corre localmente, sin subida, sin servidor.