Compresión de imágenes para la web: ¿cuánto ahorras realmente? (2026)
Compresión de imágenes para la web: ¿cuánto ahorras realmente?
Los Core Web Vitals de tu sitio están en rojo, tu score Lighthouse no se mueve por encima de 60 y la herramienta de auditoría sigue gritando sobre "properly size images" y "use modern image formats". Comprimes el peor ofensor, el peso de página cae 1,2 MB, y de repente LCP pasa de 3,4 s a 1,8 s. La compresión de imágenes sigue siendo una de las victorias de rendimiento con mayor ROI para cualquier sitio web — pero solo si entiendes qué hace realmente cada palanca.
Esta guía mide, en bytes reales ahorrados en imágenes reales, qué te da cada uno: JPG calidad 80, WebP, AVIF y resize agresivo. También cubriremos cuándo re-encodear a un formato "moderno" te cuesta más de lo que ahorra, y cómo hacer todo esto del lado del navegador con la herramienta Image Compress de Ai2Done.
TL;DR
- Redimensiona antes de comprimir — una foto 4000×3000 mostrada a 800×600 desperdicia ~95 % de sus bytes sin importar el formato. Resize primero; compresión segundo.
- JPG calidad 80 → 90 es el sweet spot para fotos — 50-70 % más pequeño que calidad 100, visualmente idéntico.
- WebP ahorra ~25-35 % sobre JPG a la misma calidad visual. Soporte universal de navegador desde 2020.
- AVIF ahorra ~50 % sobre JPG a la misma calidad visual pero añade 5-10× tiempo de codificación. Vale la pena para páginas de alto tráfico.
- Usa Ai2Done Image Compress para compresión del lado del navegador con preview side-by-side de tamaño vs calidad.
Por qué esto es más difícil de lo que parece
Pensarías que "comprime esta imagen" es una sola decisión. En la práctica, la compresión de imagen es al menos 4 palancas independientes que interactúan de formas no-intuitivas:
- Dimensiones (ancho × alto) — normalmente la palanca de mayor impacto. Una foto 4000×3000 tiene 16× la cantidad de píxeles que 1000×750.
- Formato (JPG, WebP, AVIF, PNG) — el método de codificación mismo.
- Ajuste de calidad (1-100 para JPG/WebP, ligeramente diferente para AVIF) — qué tan agresivamente descarta información el encoder.
- Profundidad de color y metadata (24-bit vs 8-bit, stripping de EXIF, perfil ICC) — normalmente una victoria pequeña pero gratis.
Una herramienta ingenua de "comprimir esta imagen" solo toca la palanca 3, dejando los mayores ahorros sobre la mesa. Las herramientas modernas — incluida la nuestra — al menos te dejan elegir las cuatro explícitamente.
La otra fuente de complicación: soporte de navegador y tu audiencia. AVIF es asombroso en Chrome, Edge, Firefox y Safari 16+; el Safari antiguo necesita fallback JPG. WebP está en todas partes excepto IE 11 (que Microsoft dejó de soportar en 2022 pero los sitios enterprise aún ven). Para la mayoría de los sitios públicos en 2026, WebP es seguro; AVIF necesita un elemento <picture> con un fallback JPG.
Mediciones del mundo real: una foto de 3 MB, comprimida de todas las formas
Tomé una imagen de prueba representativa — un shot de iPhone 4032×3024 de un skyline urbano, 3,1 MB JPG a la calidad default de la cámara (~92). Aquí está lo que cada palanca hace en aislamiento:
| Operación | Tamaño de salida | % del original | Diferencia visual |
|---|---|---|---|
| Original (JPG q92, 4032×3024) | 3,1 MB | 100 % | — |
| Resize a 1920×1440 (tamaño de hero web) | 0,95 MB | 31 % | Ninguna mostrada a tamaño hero |
| JPG calidad 85 (sin resize) | 1,4 MB | 45 % | Apenas perceptible para la mayoría de los viewers |
| JPG calidad 80 (sin resize) | 0,92 MB | 30 % | Imperceptible a distancia normal de visualización |
| JPG calidad 70 (sin resize) | 0,55 MB | 18 % | Suavidad sutil en inspección cercana |
| WebP calidad 80 (sin resize) | 0,62 MB | 20 % | Idéntico a JPG q85 |
| AVIF calidad 65 (sin resize) | 0,38 MB | 12 % | Idéntico a JPG q85 |
| Resize 1920×1440 + AVIF q65 | 0,14 MB | 4,5 % | Indistinguible para uso web |
| Resize 1920×1440 + WebP q80 | 0,23 MB | 7,5 % | Indistinguible para uso web |
| Resize 1920×1440 + JPG q80 | 0,32 MB | 10,3 % | Indistinguible para uso web |
El titular: la combinación de resize + formato moderno te da una reducción del 90-95 % sin pérdida de calidad visible. Cualquier palanca sola te lleva al 30-45 %. Esta es la razón por la que tu auditoría Lighthouse insiste tanto en "properly size" COMO en "use modern image formats" — se multiplican.
Método 1: Ai2Done Image Compress (lado del navegador, multi-palanca)
La herramienta Image Compress de Ai2Done corre las cuatro palancas en tu navegador:
- Abre /tools/image_compress en cualquier navegador moderno.
- Suelta tu/s imagen/es — se aceptan JPG, PNG, WebP, AVIF, HEIC. La subida batch funciona para hasta docenas de archivos a la vez.
- Elige formato de salida: JPG (universal), WebP (moderno, 25 % más pequeño), AVIF (moderno, 50 % más pequeño, codificación más lenta) o PNG (lossless, solo para diagramas y capturas).
- Ajusta calidad: 80 es el sweet spot universal para fotos. Baja a 70 para thumbnails; sube a 90 para imágenes hero.
- Resize opcional: fija ancho máximo o borde largo máximo. El aspect ratio se preserva automáticamente.
- Haz clic en Compress — para trabajos batch, obtén un ZIP de todas las imágenes optimizadas.
El panel lateral muestra preview side-by-side de original vs comprimido con tus ajustes actuales, con el tamaño tanto en bytes como en delta visual (PSNR, SSIM — métricas de calidad perceptual). Ajusta el slider de calidad en vivo y ve el trade-off en tiempo real antes de comprometerte.
Todo corre en tu navegador. Tus fotos nunca se suben a un servidor, incluido el nuestro. El encoder es mozjpeg-wasm para JPG, libwebp-wasm para WebP y libavif-wasm para AVIF — todas las implementaciones de referencia reales, compiladas con aceleración WASM SIMD.
Método 2: Squoosh.app (la herramienta open-source de Google)
Para una sola imagen con control muy preciso, Squoosh.app de Google es la herramienta más amada en la comunidad front-end. Misma arquitectura (todo en el navegador), UX de una-imagen-a-la-vez, con knobs extremadamente granulares para cada encoder. Es más lento para batch (sin procesamiento paralelo) y la UX asume que sabes qué hace el chroma subsampling de mozjpeg — pero para el raro "necesito perfeccionar una imagen hero", es imbatible.
Método 3: imagemin en tu build pipeline
Para optimización automatizada como parte de tu build de sitio:
npm install --save-dev imagemin imagemin-mozjpeg imagemin-webp imagemin-avif
# en tu script de build
import imagemin from 'imagemin';
import imageminMozjpeg from 'imagemin-mozjpeg';
import imageminWebp from 'imagemin-webp';
await imagemin(['src/images/*.{jpg,png}'], {
destination: 'build/images',
plugins: [
imageminMozjpeg({ quality: 80 }),
imageminWebp({ quality: 80 }),
]
});
Esta es la respuesta correcta para sitios serios que actualizan imágenes con frecuencia — la optimización corre en cada build, sin paso manual. Para batches de imagen puntuales o "añadí una imagen hero a mi sitio", la herramienta del navegador es más rápida.
Método 4: Optimización de imagen incorporada en Next.js / Astro / framework
Los frameworks modernos envían optimización de imagen incorporada que maneja todo el pipeline "resize + sirve formato moderno con fallback":
- Next.js: el componente
<Image>auto-genera srcset, sirve WebP/AVIF con fallback JPG y hace lazy-load. - Astro: el componente
<Image>hace lo mismo. - Gatsby:
gatsby-plugin-imagehace lo mismo. - Cloudflare Images: sirve cualquier imagen fuente a través de una URL transform —
?width=800&format=autoy obtén el tamaño correcto en el formato correcto para cada visitante.
Si estás construyendo un sitio nuevo, usa el handler incorporado del framework. Para un sitio estático o legacy, la compresión browser/CLI es el camino.
Cómo construimos el compresor del navegador (deep-dive técnico)
La herramienta Image Compress de Ai2Done está construida sobre tres módulos encoder WebAssembly:
- mozjpeg-wasm (encoder JPEG de Mozilla, ~10 % mejor que libjpeg-turbo a la misma calidad)
- libwebp-wasm (implementación de referencia WebP de Google)
- libavif-wasm (encoder del formato de imagen AV1, ~5-10× más lento que JPG pero produce los archivos más pequeños)
Para decoding (lado de entrada), usamos el Image y createImageBitmap incorporados del navegador para JPG, PNG, GIF, WebP, BMP e ICO — sin dependencias extra. HEIC pasa por libheif-wasm (~5 MB de bundle extra, lazy-loaded solo cuando se detecta una subida HEIC).
La elección de diseño interesante: preview en vivo side-by-side. Mientras arrastras el slider de calidad, ambos paneles se actualizan a ~60fps (imágenes pequeñas) o ~10fps (imágenes grandes), usando un OffscreenCanvas y un re-encode debounceado en un Web Worker para que la UI nunca se atasque. Esto es lo que te permite encontrar el sweet spot en segundos en vez de adivinar-y-comprobar.
Para trabajos batch, usamos un pool de Web Workers dimensionado a navigator.hardwareConcurrency - 1 para que 8 imágenes codifiquen en paralelo en una máquina de 8 cores. La codificación AVIF es el cuello de botella — limitamos paralelismo a 2 para AVIF para evitar OOMear dispositivos de gama baja.
FAQ
Q: ¿Debería usar siempre AVIF para todo? A: No siempre. AVIF da archivos ~50 % más pequeños a la misma calidad visual, pero la codificación tarda 5-10× más que JPG. Para páginas estáticas de alto tráfico, el coste de codificación es de una vez y los ahorros de ancho de banda son para siempre — vale la pena. Para imágenes generadas dinámicamente (contenido por usuario, previews en tiempo real), el coste de codificación importa más, y WebP es el mejor trade.
Q: ¿WebP / AVIF funcionarán en todos los navegadores?
A: WebP funciona en cada navegador enviado desde 2020 — Chrome, Edge, Firefox, Safari 14+, Opera. AVIF funciona en Chrome, Edge, Firefox y Safari 16+. Para visitantes de Safari <16 (~3 % del tráfico en 2026), sirve un fallback JPG vía <picture><source srcset="hero.avif" type="image/avif"><img src="hero.jpg"></picture>.
Q: ¿Comprimir quita EXIF / GPS / data de cámara? A: Por defecto, nuestra herramienta quita toda la metadata (archivos más pequeños, sin leak de GPS). Activa "Preserve EXIF" si quieres mantener ajustes de cámara o tags de orientación. Para imágenes que compartirás públicamente, default-strip es la elección correcta — la metadata GPS en fotos compartidas socialmente ha causado incidentes reales de privacidad.
Q: ¿Cuál es la diferencia entre JPG calidad 80 y JPG calidad 90? A: A calidad 90, el archivo es ~50 % más grande que a calidad 80 para salida visualmente idéntica en la mayoría de las fotos. La calidad 80 es el sweet spot universal "no puedes ver la diferencia a menos que hagas zoom 4×". Usa 90+ solo para imágenes que serán re-editadas downstream (cada pase de edición añade pérdida de calidad; empezando desde calidad 90 da más headroom).
Q: ¿Comprimir una foto a JPG calidad 80 dañará mi SEO? A: Lo opuesto — cargas de página más rápidas mejoran SEO. Los Core Web Vitals de Google (especialmente LCP) factoran en el ranking. El peso de imagen suele ser la causa #1 de LCP lento. Una imagen hero 50 % más pequeña a menudo significa un LCP medio segundo más rápido, que Google recompensa.
Q: Tengo 1000 fotos de producto para un sitio e-commerce. ¿Puedo procesarlas en batch todas?
A: Sí, pero divide en batches de 50-100 para evitar presión de memoria del navegador. Suelta 100 imágenes, obtén un ZIP, repite. Para un pipeline automatizado, configura imagemin en tu build (ver Método 3).
Pruébalo ahora
Comprime imágenes para la web en segundos, con preview side-by-side:
Abre la herramienta Image Compress →
Suelta imágenes, elige formato, arrastra el slider de calidad, observa caer los bytes. Sin subida, sin signup.
Lecturas relacionadas
- Conversión HEIC a JPG: la forma correcta en cada dispositivo — para fotos de iPhone que necesitan conversión de formato antes de compresión
- Amplía imágenes 4× con IA del lado del navegador (sin signup) — cuando necesitas más píxeles, no menos
- Image OCR: extrae texto de cualquier imagen en 100+ idiomas
- Explora todas las herramientas de imagen en el sitio principal
Última actualización 2026-06-14. La herramienta Image Compress corre 100 % en tu navegador — tus fotos nunca abandonan tu dispositivo. Nunca recopilamos, logueamos ni analizamos los archivos que procesas.