Docuboxer
Por Sergio Alonzo Piña··7 min de lectura

WebP y AVIF: por qué tu web debería usarlos ya

Qué ganan tus Core Web Vitals con WebP y AVIF, en qué navegadores funcionan hoy y cuándo todavía conviene quedarse en JPG.

Deberías usar WebP y AVIF porque, para casi cualquier fotografía o imagen con degradados, pesan bastante menos que un JPG con calidad visual comparable, y ese peso se traduce directo en tiempo de carga. La forma más rápida de comprobarlo con tus propias imágenes es abrir el conversor de imágenes de Docuboxer, subir un JPG y comparar el resultado en los tres formatos: verás la diferencia de tamaño sin subir nada a ningún servidor, porque todo el proceso corre en tu navegador.

WebP: la opción segura hoy

WebP lleva años como formato estable y lo abren de forma nativa todos los navegadores modernos de escritorio y móvil. Comprime notablemente mejor que JPG a calidad equivalente, soporta transparencia (a diferencia de JPG) y anima como GIF pero con archivos mucho más ligeros. Su codificación es rápida — similar a la de JPG — así que convertir un lote grande de imágenes no supone ninguna espera relevante. Si solo vas a adoptar un formato moderno y quieres el que menos dolores de cabeza da, es WebP.

AVIF: más compresión, pero más lento de generar

AVIF nace del códec de vídeo AV1 adaptado a imagen fija, y su algoritmo de compresión es más sofisticado que el de WebP: en fotografías grandes y en imágenes con degradados suaves, suele quedar notablemente por debajo en tamaño de archivo manteniendo un nivel de detalle comparable. El coste es la codificación: generar un AVIF exige bastante más cálculo que generar un WebP o un JPG, algo que notas sobre todo si conviertes lotes grandes o imágenes de alta resolución. Descodificarlo — verlo cargado en la página — no tiene ese coste: ahí la diferencia con WebP es insignificante.

Dónde brilla cada uno (y dónde no)

AVIF saca más ventaja cuanto más grande y compleja es la imagen: fotografías, fondos, capturas con degradados. En iconos pequeños, capturas de interfaz con bloques de color plano o imágenes de pocos píxeles, esa ventaja se reduce y a veces desaparece — el overhead del formato empieza a pesar más que lo que ahorra la compresión. Para ese tipo de gráficos, además, merece la pena evaluar si en realidad necesitas un formato de píxeles: un icono vectorial resuelto con el conversor de SVG suele pesar menos que cualquiera de los tres y además escala sin perder nitidez.

El impacto real: Core Web Vitals y LCP

En la mayoría de páginas, la imagen más grande visible al cargar (la hero, la foto de cabecera, la ilustración principal) es la que determina el LCP(Largest Contentful Paint), una de las métricas de Core Web Vitals que Google usa para evaluar experiencia de carga. Un archivo más ligero en ese elemento concreto llega antes, y el LCP mejora en consecuencia — no porque WebP o AVIF sean "mágicos", sino porque hay menos bytes que transferir y decodificar antes de pintar. El efecto es más notable en conexiones lentas o en imágenes grandes; en un icono de 3 KB la diferencia entre formatos es irrelevante para el LCP.

Antes de perseguir el formato perfecto, conviene tener el tamaño correcto: servir una imagen de 2000px de ancho para un contenedor de 400px penaliza el LCP mucho más que la elección de formato. Si todavía no has ajustado las dimensiones de tus imágenes al espacio real donde se muestran, redimensionarlas primero suele dar una ganancia mayor y más simple que cualquier cambio de códec.

El patrón <picture> con fallback

La forma correcta de servir formatos modernos sin dejar fuera a nadie es la etiqueta <picture>: ofreces varias fuentes en orden de preferencia y un <img> final que actúa como red de seguridad. El navegador prueba cada <source> de arriba a abajo y usa la primera que reconoce; si no reconoce ninguna, cae al <img>.

<picture>
  <source srcset="foto.avif" type="image/avif" />
  <source srcset="foto.webp" type="image/webp" />
  <img src="foto.jpg" alt="Descripción de la foto" />
</picture>

Con este patrón nunca hay que elegir entre compatibilidad y compresión: cada visitante recibe el mejor formato que su navegador soporta, sin JavaScript y sin negociación de contenido en el servidor.

Las fricciones reales que nadie te cuenta

Migrar no es gratis en todos los contextos, y ser honesto sobre esto ahorra sorpresas después:

  • Software de escritorio antiguo: versiones viejas de editores de imagen, algunos visores del sistema operativo y herramientas de diseño heredadas todavía no abren AVIF, y algunas ni siquiera WebP.
  • Clientes de correo: el soporte de WebP y AVIF en clientes de email es irregular; para imágenes dentro de un email sigue siendo más seguro apostar por JPG o PNG.
  • Descargas del usuario final: si tu flujo incluye que alguien descargue la imagen esperando un JPG — un catálogo, una foto de producto, un adjunto — entregarle un AVIF sin avisar genera fricción, aunque técnicamente sea un formato "mejor".
  • Herramientas internas y formularios: validaciones antiguas que solo aceptan image/jpeg o image/png rechazan los formatos modernos hasta que se actualicen explícitamente.

La solución no es evitar WebP y AVIF, es no asumir que todo el mundo los soporta en todos los contextos. Para el contenido de tu web, el patrón <picture> resuelve el problema. Para archivos que la gente va a descargar y reutilizar fuera de tu control, JPG sigue siendo la apuesta más segura.

No todo debe migrarse

Si una imagen ya es pequeña, si el ahorro de bytes es marginal frente al tamaño de tu página, o si el archivo va a viajar fuera de tu web hacia sistemas que no controlas, forzar la migración a AVIF o WebP añade complejidad sin beneficio claro. La pregunta útil no es "¿debería usar formatos modernos?" sino "¿esta imagen concreta, en este contexto concreto, se beneficia de ellos?". Para la mayoría de fotografías de un sitio web, la respuesta es sí. Para un icono de 16×16 píxeles o un archivo que un usuario va a reabrir en software que no controlas, probablemente no.

Convierte y compara en un minuto

La mejor manera de decidir es con tus propias imágenes, no con cifras genéricas. Abre el conversor de imágenes, sube una foto representativa de tu web y genera las tres versiones (JPG, WebP, AVIF): compara el tamaño resultante y la calidad visual a ojo. Si el archivo ya está en un formato pesado y solo quieres reducirlo sin cambiar de formato, el compresor de imágenes hace justo eso. Ambas herramientas procesan en tu navegador — nada se sube a un servidor, así que puedes trabajar con fotos que incluyan metadatos o información sensible sin preocuparte por dónde acaban.

Preguntas frecuentes

¿WebP o AVIF: cuál elijo en 2026?

Si necesitas la opción segura y rápida de codificar, WebP. Si el peso del archivo es lo prioritario y puedes permitirte una codificación más lenta (y aceptar algo menos de compatibilidad con software antiguo), AVIF. Muchos sitios sirven ambos con un fallback a JPG y dejan que el navegador elija el mejor que soporta.

¿AVIF funciona en todos los navegadores?

En los navegadores de escritorio y móviles actuales (Chrome, Edge, Firefox, Safari en versiones recientes) sí. El riesgo no está en el navegador del visitante, sino en software de escritorio antiguo, algunos visores de imagen del sistema operativo y ciertos clientes de correo, que todavía no lo abren.

¿Por qué AVIF tarda más en generarse que WebP?

AVIF usa un códec de vídeo (AV1) adaptado a imagen fija, con un algoritmo de compresión mucho más sofisticado que el de WebP. Esa sofisticación es la que le da mejor ratio de compresión, pero exige más cálculo al codificar. Para descodificar (verla en el navegador) la diferencia es mínima.

¿Debo convertir todas mis imágenes a AVIF?

No necesariamente. En fotografías grandes y degradados suele ganar con claridad. En iconos, capturas de interfaz con bloques de color plano o imágenes muy pequeñas, la ventaja frente a WebP se reduce o desaparece, y a veces PNG sigue siendo más simple para ese caso.

¿Qué pasa si alguien descarga un WebP o AVIF esperando un JPG?

Se encuentra con un archivo que su editor de fotos antiguo, su impresora o algún formulario que solo acepta JPG no reconoce. Es una fricción real en flujos donde el usuario final descarga la imagen (catálogos, redes sociales, adjuntos), no solo un problema técnico del servidor.

¿Cómo sirvo WebP o AVIF con fallback automático a JPG?

Con la etiqueta HTML <picture>: incluyes una fuente en AVIF, otra en WebP y una imagen <img> final en JPG. El navegador prueba las fuentes en orden y usa la primera que soporta, cayendo al JPG si no reconoce ninguna de las modernas.

Convierte tus imágenes a WebP o AVIF

Compara los tres formatos con tu propia foto. Gratis, local y sin límites.

Abrir conversor de imágenes →

Herramientas relacionadas

También te puede interesar: convertir HEIC a JPG.