Guía de compresión de imágenes: cómo elegir entre JPG, PNG y WebP
Resumen (TL;DR)
El fin de semana pasado subí una foto de gato de 4,2 MB a Squoosh con WebP en calidad 80. Salió en 380 KB —una reducción del 91%— y, sinceramente, no logro distinguirla de la original a ningún tamaño realista de pantalla. Así se ve la compresión con pérdida cuando funciona bien. Cada vez que olvido este principio, abro un blog y espero tres segundos a que aterrice un hero JPG de 2 MB sobre LTE, y la lección vuelve a llegar sola.
Elegir un formato de imagen no se trata tanto de buscar “el mejor” como de hacer coincidir el formato con un propósito. Para fotografía de tono continuo, los formatos con pérdida como JPEG, WebP con pérdida y AVIF mantienen los archivos pequeños con una diferencia perceptual mínima; a calidad visual similar, WebP suele producir archivos entre 25–35% más pequeños que JPEG, y AVIF cae alrededor de 40–50% por debajo de JPEG según los ajustes del codificador. Para logotipos, íconos, capturas de pantalla y cualquier contenido donde importan los bordes definidos o la legibilidad del texto, los formatos sin pérdida como PNG, WebP sin pérdida y TIFF son más seguros. Si necesitas transparencia y animación a la vez, WebP, APNG y AVIF son las opciones principales. La compatibilidad de navegador es amplia a comienzos de 2026: WebP funciona desde Chrome 32 (2014), Firefox 65 y Safari 14 (finales de 2020), y AVIF funciona en Chrome 85 (agosto de 2020), Firefox 93 (octubre de 2021) y Safari 16 (septiembre de 2022) en adelante. Una línea base razonable es “SVG para logotipos vectoriales, WebP o AVIF para fotos, PNG para capturas”, con un fallback a JPEG vía <picture> cuando necesitas compatibilidad con entornos antiguos.
Antecedentes y conceptos
Los formatos con pérdida (JPEG, WebP con pérdida, AVIF) reducen el tamaño descartando información a la que el sistema visual humano es menos sensible. Dos técnicas centrales lo impulsan: la cuantización, que redondea los coeficientes en el dominio de la frecuencia con más agresividad para frecuencias espaciales altas, y el submuestreo de croma, que almacena los canales de color a menor resolución que la luminancia. Un ajuste 4:4:4 preserva el croma a resolución completa, mientras que el más común 4:2:0 reduce el croma a la mitad en ambas direcciones. Ese valor por defecto está bien para la mayoría de las fotos, pero puede emborronar bordes de texto coloreado, sobre todo tipos rojos y azules sobre fondos oscuros.
JPEG, estandarizado en 1992, usa una Transformada Discreta del Coseno (DCT) por bloques aplicada a bloques de 8x8 píxeles. WebP se apoya en las técnicas intra-cuadro del códec de vídeo VP8, y AVIF utiliza el conjunto intra-cuadro de AV1. Por eso ambos son sustancialmente más modernos que JPEG en cómo predicen, transforman y cuantizan los datos de imagen, con bloques más grandes, predicción direccional y mejor codificación entrópica. PNG es otro animal: es un formato sin pérdida que usa la familia de compresión deflate, con soporte integrado para transparencia alfa y color indexado por paleta. PNG nunca descarta datos, pero para contenido fotográfico esa pureza se paga con archivos mucho más grandes.
Un concepto relacionado es la decodificación progresiva. JPEG progresivo y PNG entrelazado permiten que el espectador vea una versión de baja resolución de inmediato y la refine a medida que llegan más bytes. WebP y AVIF normalmente decodifican en una sola pasada hoy, lo cual importa sobre todo para imágenes muy grandes o conexiones lentas. Por último, SVG no es un formato ráster comprimido en absoluto, sino una descripción vectorial; el tamaño del archivo lo determinan la cantidad de formas y la compresión del propio texto (gzip y brotli son muy efectivos sobre SVG fuente).
Comparación y datos
| Formato | Con pérdida | Sin pérdida | Transparencia | Animación | Compresión típica de foto | Soporte de navegador 2025 |
|---|---|---|---|---|---|---|
| JPEG | Sí | No | No | No | Aprox. 10:1 | Todos los navegadores |
| PNG | No | Sí | Sí | Extensión APNG | Aprox. 2–3:1 | Todos los navegadores |
| WebP | Sí | Sí | Sí | Sí | 25–35% más pequeño que JPEG | Safari 14 (2020) en adelante, prácticamente universal |
| AVIF | Sí | Sí | Sí | Sí | 40–50% más pequeño que JPEG | Chrome 85+, Firefox 93+, Safari 16+ |
| GIF | Sí (paleta, 256 colores) | No | Solo 1 bit | Sí | Pobre para fotos | Todos los navegadores |
Toma estos números como tendencias generales. La compresión real depende fuertemente del contenido fuente, el codificador, el preset y la calidad objetivo. El mismo JPEG en calidad 85 y calidad 60 puede diferir 3–4x en tamaño, y la ventaja de eficiencia de AVIF se reduce cuando usas presets rápidos. Los benchmarks publicados por Google y Mozilla entre 2019 y 2023 reportaron ahorros de WebP de aproximadamente 26% a 34% frente a JPEG con SSIM equivalente, y ahorros de AVIF de aproximadamente 40% a 50% frente a JPEG, pero esos rangos asumen codificadores de preset lento y objetivos de calidad ajustados, no los valores por defecto de un clic de la mayoría de las apps de edición.
Otra dimensión es el costo de codificación y decodificación. JPEG decodifica en fracciones de milisegundo en cualquier dispositivo. WebP queda cerca. La decodificación AVIF carga más la CPU, y la codificación AVIF en presets de alta calidad puede tardar segundos por imagen. Ese perfil de costo está bien para una pipeline de assets en tiempo de build, pero resulta incómodo para contenido generado por el usuario en vivo donde un servidor reencode cada subida en la ruta caliente.
Escenarios reales
Escenario 1 — Miniaturas y hero images de blog. Hace poco audité mi propio sitio y encontré una imagen hero entregándose a 1,8 MB. Reexportar a WebP calidad 82 la dejó en 210 KB, y el Largest Contentful Paint de la página bajó de 2,4 s a 1,1 s en un perfil 4G ralentizado de Lighthouse. Toma WebP como formato principal por defecto y deja que un elemento <picture> sirva JPEG como fallback para entornos muy antiguos. Siempre redimensiona la imagen exportada al ancho real de visualización CSS; servir una foto de 3000 píxeles de ancho dentro de un contenedor de 600 píxeles desperdicia ancho de banda independientemente del formato.
Escenario 2 — Logotipos e íconos. Si tienes una fuente vectorial, exporta SVG primero. Una vez revisé una landing donde un logotipo rojo de marca había sido exportado como JPEG a calidad 75; los bordes rojos se diluían en un halo rosado alrededor de cada glifo. El submuestreo de croma 4:2:0 arruina los bordes rojo-sobre-oscuro antes que casi cualquier otra cosa. Si solo hay arte ráster, elige PNG o WebP sin pérdida. Trata la compresión con pérdida sobre logotipos como una bandera roja, no como una optimización.
Escenario 3 — Capturas de pantalla y capturas de UI. Las capturas deben usar PNG por defecto. El chrome del navegador, los snippets de código y las fuentes CJK muestran fuertemente artefactos JPEG; lo aprendí después de que un revisor de documentación marcara “fuente monoespaciada borrosa” en dos PR consecutivos. Si necesitas reducir el archivo, recurre a pngquant (en macOS, brew install pngquant) para bajar la paleta a 256 colores; las capturas de UI casi nunca muestran la diferencia, y el archivo suele encogerse 4–6x. Para sitios de docs, considera combinar PNG con marcado de imagen responsiva en CSS para que las pantallas retina reciban assets 2x mientras pantallas más antiguas descargan la versión 1x; eso suele ahorrar más bytes que cambiar de formato.
Escenario 4 — Archivado del material fuente. Para originales que podrías reprocesar más adelante (masters de fotografía, escaneos en bruto, fotos de producto), guarda una copia sin pérdida como TIFF o WebP sin pérdida en almacenamiento frío y deriva variantes de entrega con pérdida bajo demanda. Recomprimir un JPEG con pérdida repetidamente degrada la calidad en cada ciclo (“pérdida generacional”), así que conviene tener una fuente limpia a la que volver.
Errores comunes
“PNG siempre es la calidad más alta.” Es sin pérdida, lo que significa reproducción perfecta, pero para fotografías esa pureza se traduce en archivos varias veces más grandes de lo necesario. En móvil, las fotos de varios megabytes perjudican el tiempo de carga percibido y los Core Web Vitals.
“WebP no funciona en todos los navegadores.” Desde Safari 14 a finales de 2020, WebP está soportado en todos los navegadores principales. Si realmente se requiere soporte legacy, un elemento <picture> con fallback JPEG es una solución limpia.
“AVIF es mágico.” La eficiencia de compresión es excelente, pero la codificación es significativamente más lenta que JPEG o WebP. En mi MacBook Air M2, avifenc --speed 4 tarda 5–9 segundos para una sola foto de 2400×1600; en --speed 0, espera 30 s o más. La decodificación en dispositivos móviles antiguos también puede ser un problema. AVIF encaja mejor en pipelines por lotes y optimización en tiempo de build que en reencodear cada subida de usuario en la ruta caliente.
“Solo usa JPEG.” Eso era razonable hasta alrededor de 2015, pero WebP y AVIF modernos generalmente dan archivos más pequeños con calidad comparable y soporte universal o casi universal. Las pipelines nuevas deberían tomar WebP como línea base en lugar de JPEG.
“Los ajustes de calidad más altos siempre valen la pena.” Por encima de aproximadamente calidad 85 para JPEG o WebP, el tamaño del archivo crece más rápido que la calidad perceptual. Los espectadores rara vez notan la diferencia entre calidad 85 y 95, pero el archivo puede ser el doble de grande. Mide con una métrica perceptual (SSIM, butteraugli) en lugar de confiar en el deslizador de calidad como una escala lineal.
“Redimensionar no importa si comprimo bien.” Las mayores ganancias individuales en entrega de imágenes suelen venir de enviar imágenes con tamaño apropiado más que del ajuste de compresión. Un WebP de 800 píxeles de ancho es casi siempre más liviano que un WebP de 3000 píxeles, sin importar el ajuste de calidad, porque estás eliminando píxeles en lugar de aproximarlos.
Lista de verificación
- ¿La fuente es vectorial? Si sí, guarda como SVG.
- ¿Necesitas transparencia?
- Sí y el contenido es fotográfico: WebP con pérdida y alfa o AVIF.
- Sí y el contenido es un logotipo o ícono: PNG o WebP sin pérdida.
- ¿Necesitas animación? WebP animado, APNG o AVIF. La paleta de 256 colores de GIF es pobre para fotos.
- ¿El contenido es fotográfico o con muchos gradientes? Por defecto, WebP con pérdida, y añade AVIF donde el ancho de banda importa.
- ¿El contenido es una captura o UI con mucho texto? Prefiere PNG o WebP sin pérdida.
- ¿Necesitas máxima compatibilidad? Usa un elemento
<picture>con fuentes AVIF → WebP → JPEG en ese orden.
Herramienta relacionada
Puedes probar estos compromisos directamente en el compresor de imágenes de Patrache Studio referenciado en relatedToolUrl. Las imágenes suelen formar parte de una pipeline de assets más amplia, así que leer las guías compañeras ayuda: Fusión y división de PDF en el navegador cubre lo que ocurre cuando tus imágenes terminan dentro de contratos o paquetes escaneados, y Seguridad de códigos QR vale la pena leerlo si tus imágenes incluyen códigos QR escaneables sobre packaging de producto o pósteres.
Referencias
- MDN, “Image file type and format guide” — https://developer.mozilla.org/en-US/docs/Web/Media/Formats/Image_types
- web.dev, “Serve images in modern formats (WebP)” — https://web.dev/articles/serve-images-webp
- AOMedia, “AV1 Image File Format (AVIF)” especificación — https://aomediacodec.github.io/av1-avif/
- W3C, “Portable Network Graphics (PNG) Specification” — https://www.w3.org/TR/png/