La afirmación de marketing más común de las herramientas de compresión son cifras imposibles de verificar, como «reducir el volumen en un 70%». Este artículo no cita estadísticas del sector; solo expone un conjunto de resultados reales de prueba, con la metodología de control completa, que cualquiera puede reproducir.
1. Objeto de la prueba: no son originales, sino imágenes que ya han sido comprimidas una vez
La mayoría de las pruebas de compresión utilizan imágenes originales recién salidas de la cámara, una condición demasiado ideal. Esta prueba se acerca deliberadamente a un escenario real de negocio: un sitio web que permite a los usuarios subir imágenes ya ha realizado su propia ronda de compresión estándar en el momento de la ingesta; es decir, el objeto de la prueba no son imágenes crudas sin procesar, sino imágenes finales que ya han sido «comprimidas una vez».
Tamaño de la muestra: 78 carpetas, 4624 imágenes (principalmente JPG), con una estructura de directorios típica de «un álbum por carpeta», sin ningún filtrado ni limpieza.
El tamaño total original de estos archivos en el servidor: 1.41 GB.
Pregunta clave: si una imagen ya fue procesada por una herramienta de compresión, ¿cuánto espacio puede extraer otra herramienta de compresión? La intuición de la mayoría de los usuarios es: «si ya está comprimida, comprimirla de nuevo no tiene mucho sentido».
2. Grupo de control: ¿cuánto se puede ahorrar empaquetando en zip?
Antes de ejecutar ImgZilla, empaquetamos el mismo lote de archivos tal cual en un zip para observar el efecto de un algoritmo de compresión genérico:
| Volumen | Frente al original | |
|---|---|---|
| Archivos originales ya comprimidos por el sitio | 1.41 GB | — |
| Empaquetado en zip | 1.41 GB | -0.2% |
Casi sin cambios. La razón no es complicada: JPEG ya es un formato comprimido; los datos de imagen ya han pasado por codificación de entropía, y los algoritmos genéricos (zip usa DEFLATE) difícilmente pueden comprimir más datos que ya están comprimidos. Da igual si la imagen original fue procesada por el sitio o no: zip no puede hacer nada al respecto.
3. Prueba real de recompresión con ImgZilla
Arrastramos los archivos anteriores a ImgZilla y comprimimos en el lugar. Las 78 carpetas y 4624 imágenes mantienen por completo los nombres de archivo y la estructura de directorios:
| Volumen | Frente al original | |
|---|---|---|
| Archivos originales ya comprimidos por el sitio | 1.41 GB | — |
| Empaquetado en zip | 1.41 GB | -0.2% |
| Después de la recompresión con ImgZilla | 0.75 GB | -46.8% |
Sobre la base de la compresión ya realizada por el sitio, ImgZilla ahorra aproximadamente 662 MB adicionales, reduciendo el volumen casi a la mitad. Todas las rutas de carpetas, nombres de archivo y niveles jerárquicos son exactamente los mismos antes y después; son datos reales verificables, no eslogan de marketing.
Esto revela un hecho clave: «comprimida al subir al sitio» y «codificación fina con parámetros específicos del formato» son dos cosas distintas. La mayoría de los sitios aplican en la ingesta una compresión única y bastante conservadora (normalmente limitando solo el parámetro de calidad o las dimensiones), sin llegar a agotar el espacio de codificación de cada formato. ImgZilla ajusta los parámetros específicamente para cada formato y aplica a JPEG una recodificación visualmente sin pérdida: a nivel de píxeles sí hay cambios, pero los parámetros se fijan en un rango donde el ojo humano apenas puede notar la diferencia, y así se sigue extrayendo espacio sobre una imagen «ya comprimida».
Conviene aclarar un concepto que suele confundirse: «visualmente sin pérdida» no es lo mismo que «sin pérdida». La pérdida real, en sentido estricto (píxeles idénticos), solo es aplicable a PNG (oxipng) y SVG; JPEG, WebP, AVIF, HEIC y GIF son, por principio, recodificaciones con pérdida; la diferencia está en que los parámetros de compresión se controlan dentro del umbral de lo visualmente sin pérdida. ImgZilla incluye una ventana de comparación con vista en paralelo de izquierda/derecha antes y después, con zoom al tamaño real y comparación píxel a píxel, para que puedas comprobarlo tú mismo.
4. Análisis detallado: porcentaje de reducción por archivo, dimensiones en píxeles y tiempo de proceso
El 46.8% de reducción global es el resultado agregado de las 4624 imágenes. Si lo desglosamos archivo por archivo, se obtienen más detalles.
El porcentaje de reducción no es uniforme en cada imagen
Si calculamos el porcentaje de ahorro de cada imagen (bytes ahorrados sobre el tamaño original), el rango va de 32.3% a 85.8%:
- El grupo con mayor porcentaje de ahorro: de unos 765 KB a 109 KB, un 85.8% de reducción. Estas imágenes suelen haber recibido inicialmente una compresión poco intensa, así que aún hay margen de recodificación.
- El grupo con menor porcentaje de ahorro: de unos 572 KB a 387 KB, un 32.3% de reducción. Estas imágenes ya se habían comprimido bastante antes, así que queda poco margen.
- La media aritmética de los porcentajes de ahorro de las 4624 imágenes es 46.44%, cercana al 46.8% calculado por volumen total, pero no exactamente igual. La primera es un promedio simple de los porcentajes individuales; la segunda es «bytes totales ahorrados ÷ bytes originales totales». La diferencia indica que los archivos con mayor o menor porcentaje de ahorro no pesan igual en el volumen total; unos pocos archivos grandes influyen más en el total.
Cabe señalar que todos los porcentajes de ahorro son positivos; no ha habido ningún caso de «ya mínimo, se omite»: es decir, todas estas imágenes ya comprimidas por el sitio pudieron seguir reduciendo su tamaño con ImgZilla.
Dimensiones en píxeles: ni un solo cambio
Al analizar las dimensiones en píxeles de las 4624 imágenes, el formato más común es 1600×2400 (1756 imágenes), seguido de su versión horizontal 2400×1600 (500 imágenes). Las dimensiones van desde las más pequeñas, 450×675 (aprox. 300 000 píxeles), hasta las mayores, 3000×2000 / 2000×3000 (aprox. 6 millones de píxeles).
Al verificar las dimensiones de las muestras antes y después de comprimir, son exactamente iguales, sin ningún cambio:
| Archivo (ejemplo) | Dimensiones originales | Dimensiones tras comprimir |
|---|---|---|
| Muestra 1 | 1600×1066 | 1600×1066 |
| Muestra 2 | 2000×3000 | 2000×3000 |
| Muestra 3 | 1416×2128 | 1416×2128 |
Esta es la otra mitad que a menudo pasa desapercibida en la definición de «compresión en el lugar»: no solo se mantienen el nombre y la ruta del archivo, sino que la resolución permanece fija. ImgZilla no redimensiona ni recorta; toda la reducción de volumen proviene exclusivamente de la recodificación, no de sacrificar píxeles.
Tiempo de proceso: 4624 imágenes en 51 min 32 s, un promedio de 0.669 s por imagen
Entorno de prueba: Mac mini con chip Apple M1, 8 GB de memoria unificada; las imágenes están en un disco duro mecánico NAS conectado por red cableada de 2.5G.
El progreso de la tarea se siguió con la última hora de escritura de cada imagen (es decir, cuando ImgZilla terminaba de comprimir y escribía el archivo en el disco): la primera escritura fue a las 16:06:09 y la última a las 16:57:41, lo que supone un tiempo total de 51 min 32 s para todo el lote, con un promedio de 0.669 s por imagen.
Este dato coincide con el diseño de procesamiento serial del producto, que comprime las imágenes una a una en orden, en lugar de escribirlas en paralelo sin orden. En otras palabras, procesa aproximadamente 90 imágenes por minuto. La velocidad real depende del tamaño de las imágenes y del rendimiento de la máquina; el valor que mostramos aquí es solo el tiempo real de este lote (un promedio de ~305 KB por imagen) en este entorno concreto, no un punto de referencia universal.
5. Por qué se elige comprimir «en el lugar» en lugar de guardar una copia
Si la prueba hubiera usado una herramienta que «guarda una copia comprimida», el resultado habría sido: archivo original 1.41 GB + archivo comprimido 0.75 GB, ocupando en total 2.16 GB, aún más espacio; además, habría generado una gran cantidad de archivos xxx-min.jpg que habría que organizar manualmente y actualizar las referencias en bases de datos o tablas de productos.
ImgZilla usa el modo de sobrescritura en el lugar: el resultado comprimido se escribe directamente en la ruta original, y los 4624 nombres de archivo dentro de las 78 carpetas no cambian. Esto es especialmente importante para sitios que ya tienen rutas de imagen referenciadas en bases de datos, CDN o CMS: no es necesario modificar ningún enlace después de comprimir. El costo es que modifica el archivo original; por eso, por defecto, primero mueve la imagen original a la papelera del sistema y luego escribe el resultado comprimido. Si te arrepientes, puedes hacer clic derecho y elegir «Restaurar» en la papelera.
6. Análisis de beneficios: del caso real a la factura mensual
A quién le resulta útil este conjunto de datos
- Desarrolladores o sitios que aceptan subidas de imágenes de usuarios: el almacenamiento de imágenes y el tráfico de CDN suelen facturarse por GB; reducir el volumen a la mitad significa reducir la factura a la mitad. Y el tráfico es un coste que aparece cada vez que se accede a la imagen; cuanto mayor es el número de visitas, más visible es el efecto compuesto. Aunque ya se haya hecho una compresión estándar en la ingesta, esta prueba demuestra que «ejecutar una ronda adicional con parámetros específicos» todavía aporta beneficios notables.
- Servidores con poco espacio o usuarios de discos de pequeña capacidad: las herramientas de limpieza suelen eliminar cachés y archivos duplicados, pero esos archivos vuelven a acumularse a los pocos meses; en cambio, el espacio liberado por compresión proviene de archivos en uso que se han hecho más pequeños, y no vuelve a crecer. Con este lote de 78 carpetas se han liberado directamente 662 MB adicionales de espacio utilizable, y es una liberación permanente.
- Usuarios que mueven datos a menudo: al copiar, sincronizar o hacer copias de seguridad, una reducción del 46.8% recorta el tiempo de transferencia aproximadamente en la misma proporción. Comprime una vez, y cada transferencia posterior ahorra tiempo.
Convertido en factura mensual: ¿cuánto valen realmente esos 46.8%?
Para que la reducción de volumen sea convincente, tiene que reflejarse en la factura. A continuación no se citan estadísticas del tipo «la compresión mejora la conversión»: simplemente multiplicamos el 46.8% de esta prueba por las tarifas públicas de almacenamiento o tráfico de los principales proveedores de la nube, como un cálculo puramente aritmético.
Ahorro en almacenamiento = volumen ahorrado (GB) × precio unitario (yuan o dólar / GB / mes)
Ahorro en tráfico de salida = volumen ahorrado (GB) × número de descargas o accesos ese mes × precio unitario (yuan o dólar / GB)
Al reducir el volumen a la mitad, ambas partidas se reducen aproximadamente a la mitad. Esto es matemáticas, no una suposición.
Costes de almacenamiento: cuanto mayor es la colección, más evidente es el beneficio
Proveedores nacionales:
| Tamaño original de la colección | Volumen ahorrado | Almacenamiento estándar de Alibaba Cloud OSS ¥0.09/GB/mes |
|---|---|---|
| 10 GB | 4.68 GB | ¥0.42/mes |
| 100 GB | 46.8 GB | ¥4.21/mes |
| 1 TB | 479 GB | ¥43.1/mes |
Proveedores internacionales:
| Tamaño original de la colección | Volumen ahorrado | AWS S3 Standard $0.023/GB/mes |
Google Cloud Storage $0.020/GB/mes (Regional en EE. UU.) |
Azure Blob Storage $0.018/GB/mes (Hot, LRS) |
Cloudflare R2 $0.015/GB/mes |
|---|---|---|---|---|---|
| 10 GB | 4.68 GB | $0.11/mes | $0.09/mes | $0.08/mes | $0.07/mes |
| 100 GB | 46.8 GB | $1.08/mes | $0.94/mes | $0.84/mes | $0.70/mes |
| 1 TB | 479 GB | $11.02/mes | $9.58/mes | $8.62/mes | $7.19/mes |
Los precios de almacenamiento de las grandes empresas internacionales son muy similares (difieren menos de un 30%). Lo importante no es quién es más barato, sino que, con cualquiera de ellos, al reducir el volumen a la mitad, esta partida de la factura también baja aproximadamente a la mitad, y además es un cargo mensual recurrente. Una sola compresión se traduce en que todos los meses siguientes se facture sobre el nuevo volumen: es una inversión única con un beneficio que se multiplica a largo plazo.
Costes de tráfico: el verdadero gran importe, que crece con el número de visitas
El tráfico merece más atención que el almacenamiento porque es el producto de volumen × número de descargas: cuantas más veces se accede a las imágenes, mayor es el beneficio de la compresión. Supongamos una biblioteca de imágenes de 100 GB que genera 500 GB de tráfico de salida al mes a través de CDN (equivalente a la descarga completa de toda la biblioteca unas 5 veces):
| Tarifa de CDN o de tráfico de salida (primer tramo) | Factura mensual antes de comprimir | Después de comprimir (tráfico -46.8%) | Ahorro mensual | Ahorro anual |
|---|---|---|---|---|
| CDN de Alibaba Cloud nacional (tramo bajo ¥0.15/GB) | ¥75.0 | ¥39.9 | ¥35.1 | ¥421 |
| AWS CloudFront Asia-Pacífico ($0.12/GB) | $60.0 | $31.9 | $28.1 | $337 |
| Google Cloud CDN Norteamérica/Europa ($0.08/GB) | $40.0 | $21.3 | $18.7 | $224 |
| Azure Front Door estándar, Zona 1 ($0.08/GB) | $40.0 | $21.3 | $18.7 | $224 |
Hemos tomado el tramo más bajo de cada proveedor; los tramos reales suelen ser más altos (el CDN nacional de Alibaba Cloud puede llegar hasta ¥1.31/GB en el tramo más alto), y cuanto mayor es la factura, más significativo es el ahorro absoluto. Además, esta tarifa de Azure corresponde actualmente al nivel estándar de Front Door: además del tráfico de salida por GB, incluye una cuota de servicio base de aproximadamente $35/mes, que no se puede reducir con compresión y no se ha incluido en el ahorro de la tabla.
Cloudflare R2 es una excepción: su tráfico de salida es directamente $0. Si el bucket usa R2, el beneficio de la compresión se concentra casi por completo en el almacenamiento, porque el tráfico no tiene coste. Esto representa una estructura de costes distinta a la de «almacenamiento + tráfico» (como Alibaba Cloud OSS+CDN o AWS S3+CloudFront), así que conviene tener claro qué partidas se facturan antes de elegir proveedor.
Los precios unitarios anteriores son tarifas públicas recopiladas en 2026. Los precios reales pueden variar según la región, los descuentos de la cuenta y los tramos; consulta siempre los precios oficiales en tiempo real. Las cifras de descargas y visitas son supuestos de ejemplo: sustitúyelos por los datos reales de tu factura para hacer una estimación.
7. Ahorro en tiempo de transferencia y subida
Al reducir el volumen a la mitad, el tiempo de transferencia se reduce aproximadamente en la misma proporción: esta regla no depende de la factura de la nube y se aplica tanto a las copias locales y de seguridad como al proceso de subida del usuario.
Escenario local: USB 3 y red Gigabit
- Disco duro mecánico externo USB 3: el rendimiento continuo de lectura/escritura suele ser de 100–150 MB/s; tomamos la mediana, 120 MB/s.
- SSD externo USB 3: el rendimiento es claramente superior, normalmente 400–500 MB/s; tomamos 450 MB/s.
- Red cableada Gigabit (1000 Mbps): límite teórico de 125 MB/s; descontando la sobrecarga del protocolo, en pruebas reales el rendimiento sostenido es de unos 100–110 MB/s; tomamos 105 MB/s.
Estos valores son estimaciones basadas en rangos habituales de pruebas reales; la velocidad efectiva depende del medio del disco, la calidad de la interfaz y el entorno de red, y solo sirven como referencia aproximada.
| Escenario | Volumen ahorrado | USB 3 disco mecánico @120 MB/s | USB 3 SSD @450 MB/s | Red Gigabit @105 MB/s |
|---|---|---|---|---|
| Las imágenes de esta prueba | 662 MB | ≈5.5 s | ≈1.5 s | ≈6.3 s |
| Biblioteca de 10 GB | 4.68 GB | ≈40 s | ≈10 s | ≈45 s |
| Biblioteca de 100 GB | 46.8 GB | ≈6.5 min | ≈1.7 min | ≈7.4 min |
| Biblioteca de 1 TB | 479 GB | ≈66 min | ≈18 min | ≈76 min |
Los 662 MB de esta prueba pueden parecer pocos en una sola transferencia (solo unos segundos). Pero, igual que con el almacenamiento, se trata de una inversión única con beneficios permanentes: da igual si copias a un disco externo, sincronizas un NAS, ejecutas Time Machine, migras a una Mac nueva o envías los archivos a un compañero; mientras sigas moviendo estos datos, cada transferencia ahorrará proporcionalmente el mismo tiempo. Comprime una vez, y todas las transferencias posteriores ahorran tiempo.
Si la compresión ocurre antes de la subida del usuario: tiempo de espera ahorrado
Lo anterior calcula lo que se ahorra «después de almacenar las imágenes»: almacenamiento, tráfico CDN, transferencia local. Pero hay otra parte aún más interesante: el tiempo de espera entre que el usuario pulsa el botón «Subir» y la barra de progreso llega al final. Aquí se usa el ancho de banda de subida del propio usuario, que normalmente es el cuello de botella más lento de todo el recorrido: en la mayoría de las conexiones de banda ancha doméstica, la subida es solo entre una décima parte y una quinta parte de la bajada, y en redes móviles es todavía más evidente. Si, antes de que el usuario suba la imagen, el sitio o la aplicación la comprime con ImgZilla, el volumen ahorrado se convierte directamente en menos tiempo de espera.
Según el volumen medio por imagen de esta prueba: las imágenes originales ya comprimidas por el sitio tienen un promedio de 299 KB; tras la recompresión con ImgZilla, el promedio baja a 159 KB, lo que supone un ahorro medio de unos 140 KB por imagen.
| Ancho de banda de subida (rango típico de datos de pruebas de velocidad públicas; solo orientativo) | Una imagen 299 KB→159 KB |
Álbum de 50 fotos ≈15.0 MB→8.0 MB |
Las 4624 imágenes de esta prueba 1.41 GB→0.75 GB |
|---|---|---|---|
| Red móvil (combinado 4G/5G; mediana de pruebas de velocidad públicas en China aprox. 10–50 Mbps, tomamos 30 Mbps) | Ahorro ≈0.04 s | Ahorro ≈1.9 s | Ahorro ≈3 min |
| Subida de banda ancha doméstica común (planes de 100 Mb/1000 Mb de bajada; la subida suele estar limitada, aprox. 20–30 Mbps; tomamos 25 Mbps) | Ahorro ≈0.04 s | Ahorro ≈2.2 s | Ahorro ≈3.5 min |
| Subida Gigabit simétrica (pocos operadores / líneas empresariales, 1000 Mbps) | Ahorro ≈0.001 s | Ahorro ≈0.06 s | Ahorro ≈5.3 s |
| Referencia internacional: subida media de banda ancha fija en EE. UU. (datos de Ookla, 2026) | Ahorro ≈0.02 s | Ahorro ≈1 s | Ahorro ≈1.5 min |
Vista la tabla, una sola imagen puede parecer insignificante: 0.04 s es casi imperceptible, y es un resultado honesto, porque esta muestra de prueba ya era pequeña (el sitio las había comprimido antes de almacenarlas, con una media de solo 299 KB por imagen). Los escenarios donde de verdad se nota el valor son dos: subir de una vez un álbum completo o decenas de imágenes en una operación por lotes, y material de origen de mayor tamaño (como JPEG directo de cámara o contenido generado por usuarios que se sube por primera vez sin compresión previa; suelen ocupar varios MB por imagen, no cientos de KB). Con el mismo porcentaje de compresión, los segundos ahorrados de forma absoluta crecen en la misma proporción. Para los usuarios de redes móviles, que de por sí tienen una subida lenta, la reducción de la espera es aún más notable.
Las cifras de rango de las redes móviles y la banda ancha doméstica se basan en estadísticas públicas de pruebas de velocidad en China (medianas de 4G/5G y configuraciones habituales de subida en banda ancha). La velocidad real varía mucho según operador, región, dispositivo y congestión de red; úsalas solo como una referencia de orden de magnitud. Los datos de subida de banda ancha fija en EE. UU. provienen de reportajes sobre Ookla Speedtest.
¿Quieres comprobarlo tú mismo? Descarga ImgZilla directamente desde la Mac App Store, prueba con unas cuantas imágenes ya procesadas de tu propio sitio y decide si merece la pena seguir comprimiendo el resto.
Mac App Store: https://apps.apple.com/app/apple-store/id6749323539?pt=127227004&ct=v2&mt=8
Más información: https://imagetool.app/ImgZilla