Guía de formatos de imagen 2025: Cuándo elegir AVIF, WebP, JPEG o JPEG XL

Por qué las decisiones de formato de imagen todavía importan en 2025

El ancho de banda se ha vuelto más barato, pero la página web promedio sigue haciéndose más pesada. Según HTTP Archive, a finales de 2024 la página móvil mediana pesaba casi 2.2 MB, y las imágenes representaban más de 1.3 MB de esa huella. Para equipos que buscan altos puntajes de Core Web Vitals o experiencias móviles ligeras, cambiar pipelines de JPEG de una década por codecs modernos es una de las victorias más rápidas. La conversación también ha pasado de simplemente comprimir recursos a elegir el formato correcto para cada escenario—imágenes hero, texturas de UI, páginas de marketing o catálogos de archivo tienen todas necesidades diferentes.

El panorama del navegador está evolucionando rápidamente. AVIF pasó de ser una curiosidad experimental en 2023 a una capacidad predeterminada en Chromium, Firefox y Safari en 2025. JPEG XL (JXL) es técnicamente sobresaliente, pero aún se envía deshabilitado por defecto en Chromium y Firefox, mientras que Safari 17+ es el único navegador convencional que lo tiene habilitado de fábrica. Eso deja a los equipos de producto haciendo malabares entre innovación y compatibilidad. Esta guía recorre los formatos clave—JPEG, WebP, AVIF y JPEG XL—y ofrece orientación práctica para mezclarlos en producción, incluyendo cómo validar resultados con el compresor Squoosh.

Resumen: Características principales de los cuatro grandes

• JPEG sigue siendo el denominador universal. Los codificadores son rápidos, la aceleración por hardware es omnipresente y cada dispositivo heredado puede decodificarlo. Sus debilidades aparecen bajo compresión pesada (artefactos de bloqueo) y la falta de soporte nativo para transparencia o HDR.
• WebP logra un equilibrio entre eficiencia y compatibilidad. Típicamente ahorra 25–35% en archivos JPEG con calidad comparable, admite canales alfa y puede codificar animaciones cortas. La decodificación por hardware existe en la mayoría de los dispositivos modernos, manteniendo el uso de energía bajo control.
• AVIF se basa en el codec de video AV1. Admite hasta color de 12 bits, HDR y canales alfa con excelentes tasas de compresión. La codificación es intensiva en CPU, pero el beneficio visual—gradientes limpios, ruido reducido y archivos más pequeños—a menudo vale la inversión.
• JPEG XL está diseñado tanto para archivo como para entrega. Ofrece renderizado progresivo, recompresión casi sin pérdida de JPEGs heredados, transparencia alfa y flujos de animación. Su talón de Aquiles es la compatibilidad del navegador: solo Safari lo habilita por defecto, mientras que los usuarios de Chromium/Firefox deben activar un flag experimental.

Verificación de compatibilidad: Dónde funciona cada formato

Navegadores de escritorio

• Familia Chromium (Chrome, Edge, Opera, Brave): WebP y AVIF son totalmente compatibles en versiones estables. La decodificación JPEG XL existe, pero requiere que los usuarios (o administradores) activen el flag Enable JPEG XL format en chrome://flags, por lo que no puedes confiar en él para tráfico público todavía.
• Firefox: AVIF se convirtió en una característica predeterminada en la versión 113, y WebP ha estado disponible durante años. JPEG XL se puede habilitar a través de image.jxl.enabled en about:config, pero Mozilla no se ha comprometido con un cronograma estable, lo que lo hace inadecuado como formato de entrega principal.
• Safari (macOS Sonoma): Safari 17 viene con soporte AVIF y JPEG XL de fábrica. Eso hace que las plataformas Apple sean los adoptantes JXL más entusiastas en 2025, aunque todavía esperan respaldos para el resto del ecosistema.

Plataformas móviles

• iOS/iPadOS Safari & WebView: AVIF y JPEG XL están ambos habilitados, y cada aplicación que usa WebKit hereda esa capacidad. La mejora progresiva es sencilla siempre que proporciones respaldos WebP o JPEG para Android y navegadores más antiguos.
• Android Chrome & WebView: AVIF y WebP son apuestas seguras. JPEG XL permanece detrás del flag experimental, así que trátalo como una opción orientada al futuro en lugar de una dependencia.

Soporte nativo y de ecosistema

• Android & ChromeOS: Las galerías del sistema leen y escriben archivos AVIF, y algunos OEMs incluso envían AVIF como opción de cámara. El soporte JPEG XL está limitado a aplicaciones de terceros y flujos de trabajo de usuarios avanzados.
• iOS/macOS: Photos.app puede abrir AVIF, pero las exportaciones predeterminadas todavía se inclinan hacia HEIC o JPEG. La decodificación JPEG XL está en gran medida confinada a Safari y utilidades especializadas.

Conclusión: AVIF está listo para implementación mainstream en 2025. WebP sigue siendo la red de seguridad. JPEG XL es excelente para archivos o vistas previas de características, pero requiere respaldos para cualquier cosa orientada al cliente.

Calidad y tamaño de archivo: Mediciones de campo

Para fundamentar la discusión, probamos una foto de producto de 2000×2000 píxeles en diferentes formatos:

1. JPEG (Calidad 80): ~540 KB. Las texturas permanecen mayormente intactas, pero el bandeado de gradiente es visible en áreas tipo cielo.
2. WebP (Calidad con pérdida 85): ~350 KB. El manejo del ruido y la claridad de bordes superan a JPEG, convirtiéndolo en un reemplazo directo para la mayoría de las imágenes de comercio.
3. AVIF (CQ 28): ~210 KB. Los detalles finos y las texturas de poca luz se conservan, y el sangrado de color es mínimo. Los ahorros se acumulan rápidamente en páginas con muchas imágenes.
4. JPEG XL (Distancia 1.0, aproximadamente Calidad 92): ~260 KB. Ofrece los detalles más limpios y una excelente preservación de gradientes, aunque el tiempo de codificación fue aproximadamente 1.5× AVIF en nuestras pruebas.

Para recursos de UI con transparencia, AVIF sin pérdida típicamente comprime 15–25% más pequeño que PNG y ligeramente mejor que WebP sin pérdida. AVIF de alta profundidad de bits (10 o 12 bits) también brilla para fotografía HDR, lo cual es cada vez más relevante en pantallas OLED y mini-LED.

Consideraciones de rendimiento y control de costos

• Velocidad de codificación: JPEG gana, seguido de WebP. AVIF y JPEG XL demandan más tiempo de CPU, así que planea pipelines multi-hilo o servicios administrados si procesas lotes grandes.
• Sobrecarga de decodificación: El hardware moderno decodifica AVIF eficientemente, pero los dispositivos Android de gama baja pueden mostrar un pico de CPU del 5–10% en comparación con JPEG. Usa dimensionamiento responsivo, carga diferida y técnicas de marcador de posición para compensar el impacto.
• Comportamiento de CDN: Los principales CDNs (Cloudflare, Fastly, Akamai) almacenan en caché AVIF/WebP sin configuración especial. Asegúrate de que tus encabezados Vary o reglas de negociación eviten el envenenamiento de caché al servir diferentes formatos a diferentes clientes.

Estrategias de respaldo que realmente funcionan

1. Negociación de contenido: Haz que tu backend inspeccione el encabezado Accept. Si image/avif está presente, sirve AVIF; de lo contrario vuelve a WebP, luego JPEG.
2. Elemento <picture>: Incorpora mejora progresiva en plantillas:

   <picture>
     <source srcset="hero.avif" type="image/avif" />
     <source srcset="hero.webp" type="image/webp" />
     <img src="hero.jpg" alt="Hero de producto" loading="lazy" />
   </picture>

Los navegadores eligen automáticamente la primera fuente compatible. Los clientes más antiguos llegan al respaldo JPEG sin ningún scripting.

1. Salida múltiple en tiempo de construcción: Genera variantes AVIF, WebP y JPEG durante CI/CD, usando herramientas como @oneimage/squoosh, Sharp o ImageMagick. Esto evita la latencia de transcodificación sobre la marcha en producción.
2. Mediación Service Worker: En Progressive Web Apps, usa un Service Worker para detectar soporte, almacenar en caché múltiples variantes y degradar elegantemente cuando esté offline. Esto también reduce descargas duplicadas cuando los usuarios cambian entre dispositivos.
3. Optimizadores CDN: Servicios como Cloudflare Images, Imgix o ImageKit pueden negociar formatos automáticamente. Confirma sus hojas de ruta JPEG XL antes de habilitar JXL en producción para evitar fragmentación de caché.

Recomendaciones basadas en escenarios

Comercio y páginas de destino

• Principal: AVIF para imágenes hero y tomas de productos.
• Respaldos: WebP y JPEG para cubrir builds antiguos de Chromium y navegadores de nicho.
• Consejo: Mantén un master JPEG de alta calidad para flujos de trabajo de descarga o impresión.

Plataformas sociales y UGC

• Principal: WebP para codificación rápida durante cargas.
• Mejoras: Genera AVIF para feeds premium o pantallas de alta densidad. Archiva archivos fuente como JPEG XL para eficiencia de almacenamiento a largo plazo.

Archivos profesionales y sistemas DAM

• Principal: JPEG XL sobresale en compresión casi sin pérdida y puede reducir bibliotecas JPEG heredadas en 20–30% sin pérdida visible.
• Entrega: Convierte a AVIF/WebP al distribuir a navegadores hasta que el soporte JXL sea omnipresente.

Elementos de UI e iconos

• Principal: AVIF sin pérdida para recursos de UI semitransparentes, gradientes y sombras.
• Respaldo: WebP sin pérdida para compatibilidad, manteniendo SVG para iconografía vectorial.

Animación y microinteracciones

• Principal: WebP animado está probado en batalla y es mucho más ligero que GIF.
• Lista de seguimiento: AVIF animado ofrece incluso mejor compresión, pero Safari todavía está puliendo controles de reproducción y peculiaridades de rendimiento. Úsalo experimentalmente con respaldos.

Blueprint de flujo de trabajo de equipo

1. Define una matriz de formatos: Documenta qué formatos se aplican a banners hero, miniaturas, fondos, etc. Esto reduce las conjeturas y previene ejercicios de bomberos de último minuto.
2. Automatiza la compresión: Integra verificaciones de formato en CI para bloquear cargas JPEG o PNG de gran tamaño. Aprovecha herramientas CLI o pipelines basados en @oneimage/squoosh, Sharp o libvips.
3. Nomenclatura consistente: Agrega descriptores como @2x, -dark o -mobile a archivos de salida para simplificar la gestión de recursos.
4. QA visual: Antes del envío, ejecuta recursos a través del compresor Squoosh para inspeccionar regiones ampliadas, artefactos de submuestreo de croma y deltas de tamaño de archivo. El procesamiento basado en navegador mantiene archivos sensibles en la máquina del revisor.
5. Comparte conocimiento: Actualiza documentos del sistema de diseño o playbooks de ingeniería con las últimas notas de compatibilidad. Revisa el playbook trimestralmente mientras los proveedores de navegadores ajustan sus hojas de ruta.

Práctica con Squoosh: Flujo de trabajo de tres pasos

1. Suelta un archivo fuente: Arrastra un JPEG, PNG o HEIC en Squoosh. La aplicación genera una vista previa inmediata sin cargar nada a un servidor.
2. Comparación de pantalla dividida: Asigna AVIF al panel izquierdo y WebP o JPEG al derecho, luego amplía áreas con gradientes, texto o texturas finas para juzgar la fidelidad.
3. Exporta múltiples objetivos: Encola salidas AVIF, WebP y JPEG XL en una sesión. Usa procesamiento por lotes para procesar carpetas completas al incorporar nuevas campañas o migrar archivos.

Squoosh también expone controles avanzados como eliminación de ruido, submuestreo de croma y ajustes preestablecidos de velocidad/calidad. Estos facilitan documentar configuraciones repetibles para diseñadores y desarrolladores, reduciendo debates subjetivos sobre calidad "suficientemente buena".

Perspectiva futura: ¿Cuándo despegará JPEG XL?

Técnicamente, JPEG XL combina los aspectos destacados de JPEG 2000, WebP y BPG—compresión robusta, renderizado progresivo, soporte HDR y animación—mientras también permite transcodificación casi sin pérdida de catálogos JPEG existentes. Las comunidades de fotografía y los proveedores DAM ya lo tratan como el heredero presunto de JPEG.

El punto crítico es la política del navegador. Los mantenedores de Chromium están evaluando señales de adopción y complejidad de implementación, y no han establecido una fecha para habilitar JXL por defecto. Firefox refleja esa cautela. Hasta que esos interruptores cambien, los equipos deben tratar JPEG XL como un formato de archivo u opt-in en lugar de un predeterminado de envío.

Dicho esto, prepararse para la transición es inteligente. Si tu pipeline ya puede generar JXL junto a AVIF/WebP, puedes cambiar la entrega tan pronto como los navegadores se pongan al día—sin reprocesar terabytes de imágenes fuente.

Lista de verificación de acción

• Envía AVIF ahora: El soporte del navegador es estable y los ahorros de tamaño son sustanciales.
• Mantén respaldos WebP y JPEG: El patrón <picture> y la negociación de contenido cubren navegadores de cola larga sin JavaScript adicional.
• Monitorea el progreso de JPEG XL: Úsalo para archivos y usuarios avanzados, pero mantén respaldos hasta que Chromium y Firefox lo habiliten por defecto.
• Invierte en automatización: Incorpora conversión de formato en CI/CD para evitar errores humanos y apuros de último minuto.
• Usa Squoosh para verificación: Estandariza en Squoosh para validar calidad visual y objetivos de compresión antes del lanzamiento.

Tratar los formatos de imagen como un activo estratégico en lugar de una ocurrencia tardía paga dividendos en rendimiento, accesibilidad y satisfacción del usuario. Con un playbook deliberado y las herramientas correctas, puedes entregar visuales más nítidos, páginas más rápidas y audiencias más felices durante 2025 y más allá.