En el artículo anterior la prueba fue con imágenes finales que el sitio web ya había comprimido una vez, e ImgZilla ahorró un 46,8 % más. Esta vez pasamos al otro extremo: imágenes originales salidas directamente de cámara y móvil, sin haber sido procesadas por ninguna herramienta. Tampoco citaré estadísticas del sector; solo mostraré el resultado de una prueba real, con su método de comparación.
1. El objeto de esta prueba: los «originales» reales
Las muestras del artículo anterior tenían una premisa: esas imágenes habían pasado por una ronda de compresión del sitio web al ser almacenadas, por lo que ya no eran originales. Esta vez he quitado esa premisa y pruebo JPEG exportados directamente por la cámara / el móvil después de disparar, sin pasar por ninguna herramienta de compresión, sin guardar otra copia y sin una segunda codificación.
Tamaño de la muestra: 32 188 JPEG, organizados en 16 subdirectorios «bucket», sin seleccionar ni limpiar nada para la prueba.
Volumen total de estos archivos: 99,9 GB (aprox. 93 GiB).
Las especificaciones de las imágenes también son típicas: todas son resoluciones estándar de salida de cámara / móvil:
| Resolución | N.º de archivos | Porcentaje |
|---|---|---|
| 4000×3000 (12 MP) | 19867 | 61,7 % |
| 4032×3024 (12 MP, iPhone) | 3529 | 11,0 % |
| 3456×4608 (16 MP vertical) | 2631 | 8,2 % |
| Otras (3120×4208, 4608×3456, 2448×3264…) | 6161 | 19,1 % |
Media de 11,5 megapíxeles y 2,96 MB por imagen; la imagen más grande pesa 18,3 MB y tiene 30 megapíxeles. Son las fotos que una cámara o un móvil toma y que tú nunca has tocado.
La pregunta es: ¿cuánto puede exprimir una herramienta de compresión especializada a unos originales que «nadie ha tocado»?
2. Resultado: un 76,8 % menos; 99,9 GB se convierten en 23,1 GB
Las 32 188 imágenes se comprimieron una a una en el mismo lugar, sin cambiar nombres de archivo, estructura de directorios ni resolución:
| Volumen | Respecto al original | |
|---|---|---|
| Original directo de cámara | 99,9 GB | — |
| Tras comprimir con ImgZilla | 23,1 GB | -76,8 % |
Una sola compresión ahorra unos 76,7 GB; después queda menos de una cuarta parte del tamaño original. Las rutas relativas, los nombres de archivo y la jerarquía de directorios de los 32 188 archivos son exactamente los mismos antes y después; esto puede comprobarse directamente sobre los datos reales.
Comparación con el artículo anterior:
| Lote de prueba | Origen de las imágenes | Tasa de compresión de ImgZilla |
|---|---|---|
| Artículo anterior (4 624 imágenes) | Imágenes finales que el sitio ya había comprimido una vez | -46,8 % |
| Este artículo (32 188 imágenes) | Originales directos de cámara / móvil | -76,8 % |
La conclusión es directa: cuanto menos procesada está una imagen original, más espacio se puede aprovechar. La compresión que hizo el sitio al almacenar las imágenes ya se había comido parte de la redundancia, dejando a ImgZilla un 46,8 %; en cambio, en los originales directos de cámara esa redundancia no se ha tocado en absoluto, e ImgZilla puede eliminar el 76,8 % de una sola vez.
3. Por qué los originales de cámara pueden ahorrar tanto
Cuando la cámara y el móvil exportan JPEG, su prioridad es «no perder detalles», no «que el archivo pese lo menos posible». Por eso, los JPEG de salida directa contienen mucho volumen que no contribuye a la calidad de imagen:
- Parámetros de calidad conservadores: los JPEG directos suelen usar una tabla de cuantificación con calidad 90–98; el ojo humano ya no distingue la diferencia de una calidad mayor, pero el número de bytes cambia mucho.
- Codificación de entropía genérica y no óptima: la codificación directa usa una tabla Huffman estándar fija, no calcula una codificación óptima para cada imagen, ni aplica cuantización trellis ni optimización de escaneo progresivo.
- Una gran cantidad de datos adjuntos: EXIF, GPS, campos privados del fabricante, una miniatura de vista previa incrustada de la imagen completa, perfiles de color... En conjunto, suman a menudo desde decenas hasta cientos de KB.
ImgZilla hace una recodificación visualmente sin pérdidas de los JPEG: reordena la codificación de entropía con una estrategia mejor, ajusta los parámetros de cuantificación a un rango que el ojo no puede distinguir y elimina los datos adjuntos redundantes. A nivel de píxel sí hay cambios, pero los parámetros se eligen en un punto donde apenas se nota la diferencia; por eso, con originales con tanta redundancia, puede quitar tres cuartas partes de una vez.
Hay que aclarar un término que se confunde con facilidad: «visualmente sin pérdidas» no es igual a «sin pérdidas». Sin pérdidas (los píxeles no cambian en absoluto) solo ocurre con PNG (oxipng) y SVG; JPEG, WebP, AVIF, HEIC y GIF son, por naturaleza, recodificación con pérdida, solo que los parámetros de compresión se eligen dentro del rango visualmente sin pérdidas. Si no quieres fiarte solo de esta afirmación, ImgZilla incluye una ventana de comparación con vista dividida izquierda/derecha antes y después, ampliable al tamaño real para comparar píxel a píxel; compruébalo tú mismo.
4. Analizándolo en detalle: ratio de compresión por archivo, dimensiones en píxeles y casos extremos
El 76,8 % anterior es la comparación del volumen total de todo el lote de 32 188 imágenes. Si se desglosa hasta el nivel de archivo individual, se ven varias cosas más concretas.
La gran mayoría de las imágenes ahorran entre un 70 % y un 90 %
Emparejando las 32 188 imágenes una a una según «bytes antes de comprimir → bytes después de comprimir» y agrupándolas por el porcentaje ahorrado:
| Porcentaje ahorrado | N.º de imágenes | Porcentaje |
|---|---|---|
| 90 %–100 % | 866 | 2,7 % |
| 80 %–90 % | 11375 | 35,3 % |
| 70 %–80 % | 15244 | 47,4 % |
| 60 %–70 % | 3349 | 10,4 % |
| 50 %–60 % | 398 | 1,2 % |
| Menos del 50 % | 956 | 3,0 % |
El 82,7 % de las fotos ahorró entre un 70 % y un 90 %. La media aritmética de la tasa de compresión por archivo es del 76,6 %, casi idéntica al 76,8 % calculado sobre el total de bytes; esto indica que, en este lote, las imágenes que más se comprimen y las que menos se comprimen están distribuidas de forma bastante uniforme en peso, sin estar sesgadas por unos pocos archivos enormes.
Por cuantiles: más de la mitad de las fotos ahorran más del 77 %; incluso el 10 % con peor rendimiento de compresión ahorra alrededor del 68 %; solo cerca del 1 % de las fotos (p99) ahorra menos del 40 %.
Dimensiones en píxeles: ni un píxel ha cambiado
Al comprobar los cambios de resolución de las 32 188 imágenes, dimensions_changed es false en todas: el 100 % conserva la resolución original. ImgZilla no redimensiona ni recorta; los 76,7 GB ahorrados provienen íntegramente de la recodificación, no de restar píxeles. Es la mitad de la definición de «compresión en sitio» que a menudo se ignora: no solo el nombre de archivo y la ruta no cambian, sino que la resolución tampoco se toca.
Algunos casos extremos
| Tipo | Original | Comprimido | Ahorro |
|---|---|---|---|
| Mayor tasa de compresión | 3,55 MB (4000×3000) | 100 KB | 97,2 % |
| Mayor ahorro en una sola imagen | 17,90 MB (4000×3000) | 1,13 MB | 16,8 MB |
| Peor rendimiento | 70 KB (1242×1242) | 68,8 KB | 2,1 % |
El grupo con mayor tasa de compresión (ahorro superior al 95 %) suele ser el de imágenes tomadas con parámetros de calidad muy altos y cargadas de metadatos; las de peor rendimiento son imágenes que ya eran muy pequeñas y habían sido procesadas antes. En promedio se ahorran 2,38 MB por imagen.
5. Convirtiendo el ahorro en la factura mensual: ¿cuánto vale ese 76,8 %?
Solo cuando se reduce el volumen se nota en la factura. A continuación no cito ninguna estadística del tipo «la compresión mejora la conversión»; solo hago una cosa: tomar el 76,8 % real y multiplicarlo por las tarifas públicas actuales de varios proveedores de nube, con un cálculo puramente aritmético.
Ahorro en almacenamiento = volumen ahorrado (GB) × precio unitario (yuanes o dólares / GB / mes)
Ahorro en tráfico de salida = volumen ahorrado (GB) × número de descargas en el mes × precio unitario (yuanes o dólares / GB)
Coste de almacenamiento
| Tamaño original de la biblioteca | Volumen ahorrado | Alibaba Cloud OSS Standard ¥0,09/GB/mes |
AWS S3 Standard $0,023/GB/mes |
Google Cloud Storage $0,020/GB/mes |
Cloudflare R2 $0,015/GB/mes |
|---|---|---|---|---|---|
| 10 GB | 7,68 GB | ¥0,69/mes | $0,18/mes | $0,15/mes | $0,12/mes |
| 100 GB | 76,8 GB | ¥6,91/mes | $1,77/mes | $1,54/mes | $1,15/mes |
| 1 TB | 786 GB | ¥70,8/mes | $18,1/mes | $15,7/mes | $11,8/mes |
| Este lote real de la prueba (99,9 GB) | 76,7 GB | ¥6,90/mes | $1,76/mes | $1,53/mes | $1,15/mes |
Es un cargo que se repite cada mes; se comprime una vez y, a partir de entonces, todos los meses se factura por el nuevo volumen: inversión única y beneficio a largo plazo.
Tráfico: el verdadero gasto importante
El coste de tráfico 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. Por ejemplo: una biblioteca de imágenes de 100 GB que genera 500 GB de tráfico de descarga mensual a través de CDN (equivalente a descargar toda la biblioteca unas 5 veces), con el tráfico reducido proporcionalmente al volumen, -76,8 %:
| Tarifa de salida de CDN (primer tramo) | Coste mensual antes | Después de comprimir | Ahorro mensual | Ahorro anual |
|---|---|---|---|---|
| Alibaba Cloud CDN China (¥0,15/GB) | ¥75,0 | ¥17,4 | ¥57,6 | ¥691 |
| AWS CloudFront Asia-Pacífico ($0,12/GB) | $60,0 | $13,9 | $46,1 | $553 |
| Google Cloud CDN Norteamérica/Europa ($0,08/GB) | $40,0 | $9,3 | $30,7 | $369 |
Se han tomado las tarifas del primer tramo (las más bajas) de cada proveedor; las tarifas reales por escalones suelen ser más altas. Cuanto mayor es la factura, más notable es el ahorro absoluto que aporta la compresión. Cloudflare R2 es la excepción: el tráfico de salida es de $0, por lo que el beneficio se refleja casi por completo en el almacenamiento.
Los precios unitarios anteriores son un resumen de las tarifas públicas de cada plataforma en 2026. Los precios reales varían según la región, los descuentos de la cuenta y el tramo aplicado; consulta siempre los precios vigentes en la web oficial. El número de descargas es una suposición de ejemplo; sustitúyelo por las cifras reales de tu propia factura.
6. Escenario local: cuánto tiempo de espera ahorra mover estos datos
Al reducir el volumen un 76,8 %, el tiempo de transferencia se acorta casi en la misma proporción. Esto no necesita una factura de nube para cumplirse; se nota directamente en el tiempo de espera de las copias y las copias de seguridad.
- Disco duro mecánico portátil USB 3: se toma un rendimiento sostenido de 120 MB/s.
- Unidad de estado sólido portátil USB 3: se toma 450 MB/s.
- Red cableada gigabit: restando la sobrecarga del protocolo, se toma 105 MB/s.
| Escenario | Volumen ahorrado | Disco mecánico USB 3 | SSD USB 3 | Red gigabit |
|---|---|---|---|---|
| Este lote real de la prueba | 76,7 GB | ≈11 min | ≈2,9 min | ≈12,5 min |
| Biblioteca de 10 GB | 7,68 GB | ≈66 s | ≈17 s | ≈75 s |
| Biblioteca de 100 GB | 76,8 GB | ≈11 min | ≈2,9 min | ≈12,5 min |
| Biblioteca de 1 TB | 786 GB | ≈112 min | ≈30 min | ≈128 min |
Igual que con el almacenamiento, es una inversión única que se amortiza a largo plazo: copiar de un disco externo a otro, sincronizar un NAS, ejecutar Time Machine, migrar a un equipo nuevo, enviar a un compañero... mientras sigas moviendo estos datos, cada vez se ahorra tiempo en esa proporción.
7. Si la compresión ocurre antes de que el usuario suba el archivo
Lo calculado antes es el coste «una vez que la imagen ya está guardada». Pero hay otro tramo que merece aún más la pena calcular: el tiempo desde que el usuario pulsa «subir» hasta que la barra de progreso se completa. Ese tiempo se consume en el ancho de banda de subida del propio usuario, y la subida casi siempre es el eslabón más lento de toda la cadena. Los originales directos de cámara pesan varios MB por imagen, un orden de magnitud más que las imágenes finales del artículo anterior (ya comprimidas por el sitio, con una media de 299 KB), por lo que la diferencia de tiempo en este tramo es mucho más evidente.
Según el volumen medio por imagen medido en este lote: los originales de cámara pesan una media de 2,96 MB; después de ImgZilla, la media es de 0,69 MB, unos 2,27 MB menos por imagen.
| Ancho de banda de subida (rango típico en pruebas de velocidad públicas; solo referencia) | Una imagen 2,96 MB → 0,69 MB |
Subir un álbum de 50 fotos ≈148 MB → 34 MB |
Subir las 32 188 imágenes de este lote 99,9 GB → 23,1 GB |
|---|---|---|---|
| Red móvil (4G/5G combinado, 30 Mbps) | ahorra ≈0,6 s | ahorra ≈30 s | ahorra ≈5,7 h |
| Banda ancha doméstica común (subida, 25 Mbps) | ahorra ≈0,7 s | ahorra ≈36 s | ahorra ≈6,8 h |
| Fibra simétrica gigabit (1000 Mbps) | ahorra ≈0,02 s | ahorra ≈0,9 s | ahorra ≈10 min |
Ahorrar 0,6 s por imagen aún no se nota, pero al subir un álbum completo de una vez o al importar en lote varios cientos de originales de cámara, los minutos ahorrados se notan con claridad, sobre todo para los usuarios de redes móviles, cuya subida ya es lenta de por sí.
Las cifras de rango provienen de estadísticas públicas de pruebas de velocidad en China; la velocidad real se ve muy influida por el operador, la región, el dispositivo y la congestión de la red. Solo sirven como referencia de orden de magnitud.
8. Datos y notas sobre la prueba
- Alcance de la muestra: los datos de este artículo provienen de la prueba real de este lote de 32 188 JPEG directos de cámara / móvil y reflejan el resultado de esta muestra; no significa que ImgZilla pueda comprimir de media un 76,8 %. Con cámaras o modelos distintos los resultados varían; en imágenes ya optimizadas en detalle, el margen aprovechable será bastante menor.
- Selección de la muestra: el lote completo se comprimió sin filtrar ni limpiar, según los 16 subdirectorios originales; no se han seleccionado muestras favorables.
- Comparabilidad con el artículo anterior: el 46,8 % del artículo anterior y el 76,8 % de este se diferencian casi por completo en si el material había sido comprimido con anterioridad. La mayoría de las bibliotecas de imágenes se encontrarán entre estas dos cifras: las que ya se comprimieron al entrar se acercan más al 46,8 %, y los originales que el usuario sube por primera vez, más al 76,8 %.
- Criterio estadístico: el 76,8 % del texto es «bytes totales ahorrados ÷ bytes totales originales»; la media aritmética de la tasa de compresión por archivo es del 76,6 % y la mediana del 77,3 %; ambos criterios se han indicado en el cuerpo del artículo. Las unidades de volumen se convierten según 1 GB = 10⁹ bytes.
- Parámetros de compresión: los parámetros son fijos; la interfaz no tiene control deslizante de calidad. Es una decisión de diseño: los parámetros de cada formato están ajustados al punto de equilibrio dentro del rango visualmente sin pérdidas. Quienes estén acostumbrados a ajustar los parámetros manualmente deben tenerlo en cuenta.
- Entorno de ejecución: todo se realizó en este equipo; las imágenes no salen de esta Mac y no se necesita conexión a internet (salvo para la verificación de compra en la App Store).
Fuentes de precios de referencia (tarifas públicas de 2026; consulta siempre los precios actualizados en el sitio oficial de cada plataforma): AWS S3 Pricing, Tarifas de Alibaba Cloud OSS, Google Cloud Storage Pricing, Cloudflare R2 Pricing, Tarifas de Alibaba Cloud CDN, AWS CloudFront Pricing, Google Cloud CDN Pricing.
¿Quieres comprobarlo tú mismo? Descarga ImgZilla directamente desde la Mac App Store, haz la prueba con varias imágenes ya procesadas de tu propio sitio y decide después si 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
Requisitos del sistema: macOS 12.3 o superior.