ZIP vs 7Z vs ZSTD: la comparativa definitiva con datos reales

Elegir entre ZIP, 7Z y ZSTD parece cuestión menor hasta que necesitas desplegar aplicaciones, enviar backups a diario o reducir costes de almacenamiento y ancho de banda (ver cómo comprimir y descomprimir archivos). En la práctica, la decisión cambia los tiempos de entrega, el consumo de CPU/RAM y hasta la compatibilidad con herramientas y sistemas de terceros.

Tras revisar múltiples benchmarks con datos reales y contextos muy distintos —desde un dataset de 5,4 GB .NET para despliegues, pasando por un corpus de texto de Wikipedia de 1 GB, a imágenes de contenedor y un binario de 28,7 GB— la foto completa revela cuándo conviene priorizar ratio, dónde manda la velocidad de descompresión y qué implicaciones tiene la compatibilidad (ZIP clásico, ZIP con ZSTD, 7Z con LZMA2 o con códecs alternativos, etc.).

Qué comparamos y por qué importa

Hemos analizado las familias más usadas: ZIP (Deflate), 7Z (LZMA/LZMA2) y ZSTD. Además, entran en la conversación Brotli, XZ, bzip2, zpaq y LZ4, porque en la vida real casi nunca es un «cara a cara» puro. En despliegues .NET, por ejemplo, el equilibrio entre compatibilidad, ratio y velocidad pesa de forma distinta que en backups masivos o en empaquetado de paquetes de distribución.

El contexto manda: si buscas mínimo tiempo de despliegue y soporte omnipresente, no eliges igual que cuando intentas minimizar el almacenamiento de 15 copias de seguridad (y dividir archivos comprimidos) y optimizar el coste de egress. Lo bueno es que ahora hay cifras comparables y patrones claros para decidir con cabeza.

Cómo trabaja cada formato (y qué significa en la práctica)

• ZIP (Deflate) combina LZ77 y Huffman; es el veterano, ubicuo y compatible hasta la médula. No suele ganar en ratio ni en velocidad de compresión frente a opciones modernas, pero abre en cualquier sitio (ver cómo gestionar extensiones del explorador) y su implementación es estable y conocida. El ZIP tradicional (método 8) tenía límites históricos, aunque los compresores modernos sortean gran parte de esas trabas.
• 7Z se apoya sobre todo en LZMA/LZMA2, con muy buen ratio y herramientas maduras. Además, 7-Zip paraleliza bien y sus «defaults sensatos» lo hacen sentir ágil. Es un estándar de facto en entornos de escritorio y devs, con soporte amplio en Windows, Linux y macOS (a veces tirando de utilidades externas).
• Zstandard (ZSTD), creado por Facebook (2015), destaca por descompresión extremadamente rápida y una paleta de niveles muy amplia (1–22). Su objetivo es rendir igual o mejor que Deflate y acercarse a LZMA en ratio, con una ejecución generalmente más veloz. Lo vemos integrado en kernels BSD/Linux, compresión de paquetes (p. ej. Arch Linux usa zstd nivel 20, descomprimiendo 14× más rápido que XZ con apenas +0,8% de tamaño) y cada vez más presente en flujos CI/CD.

Otros actores que conviene conocer

• Brotli, pensado para la Web, comprime mejor que gzip en contenido textual y se beneficia del content-encoding de los navegadores. Su referencia de compresión es monohilo, lo que sesga comparativas de tiempo real wall-clock si lo enfrentas a códecs multihilo, pero hay implementaciones paralelas. En entornos de servidor, el consumo de CPU total (user+sys) es más relevante que el reloj de pared.
• XZ mejora LZMA y ofrece gran ratio a costa de tiempos de compresión altos. En binarios grandes puede ser competitivo, pero su velocidad de descompresión suele quedar detrás de ZSTD y 7Z. Concurrencia multihilo y el parámetro -e (extreme) mejoran algo la foto, aunque no hace milagros.
• bzip2/pbzip2 equilibran ratio y CPU más o menos en medio del tablero. Con pbzip2 se gana paralelismo. Sin embargo, para muchos casos modernos ZSTD y 7Z ofrecen mejores trade-offs globales.
• zpaq es el «todoterreno del ratio máximo» con compresión incremental tipo journaling; su foco está en exprimir bytes, sacrificando con gusto la velocidad de descompresión. Para backups fríos puede ser buena idea; para consumo general, no.

Benchmarks con datos: texto, binarios grandes y despliegues

1) Dataset textual (Wikipedia 1 GB)

En una comparativa de ZIP (via 7zip), 7zip, XZ, Brotli, Zstandard, zpaq sobre 1 GB de texto de Wikipedia, se graficaron tiempo vs tamaño en cada nivel. El autor avisa: pruebas no científicas y Brotli referencia monohilo penaliza los tiempos «reales». En cómputo user+sys la foto mejora para Brotli; ZSTD aparece muy competitivo, descomprimiendo rapidísimo y con ratios en la órbita de XZ/7zip a esfuerzos elevados.

Hallazgos clave: ZIP queda por detrás en ratio y tiempo de compresión; 7zip avanza con herramientas más cuidadas y multihilo; XZ mejora ratio pero decomprime más lento que ZSTD; ZSTD equilibra fantásticamente al subir esfuerzo; y zpaq logra ratios top pagando muchísimo tiempo, sobre todo en descompresión.

2) Prueba «máxima compresión» de PeaZip (Windows, i7-8565U)

Con PeaZip/WinRAR, archivo de entrada 303,0 MB y cinco repeticiones por test, estos fueron los valores promedio (tamaños en MB; tiempos en s):

Conclusiones: ZPAQ gana en ratio puro pero es muy lento, incluso al extraer. 7Z (LZMA2) ofrece buen ratio, con extracción razonable. Usando Brotli/ZSTD dentro de 7Z, la extracción vuela (Brotli aún más), a cambio de compresiones más largas que LZMA2 en ultra. RAR prioriza velocidad de compresión sacrificando algo de ratio, y si necesitas seguridad, puedes ver cómo poner contraseñas a archivos comprimidos.

3) Binario enorme de 28,7 GB (Linux, Ryzen 5 5600G)

Sobre un archivo de 28,65–28,7 GB, el objetivo era comprimir al máximo y comparar ratios y tiempos con xz, pbzip2, 7z y zstd:

• xz -9e -T12: 12,6 GiB en ~15m49s (≈ 44,0%)
• pbzip2 -9: 13,07 GiB en ~4m29s (≈ 44,55%)
• 7z -mx=9: 12,9 GiB en ~16m43s (≈ 43,98%)
• zstd –ultra -22 -T12: 12,48 GiB en ~19m48s (≈ 43,57%)

En «máxima compresión», ZSTD ganó por poco en tamaño, pero tardó más. pbzip2 sorprendió en velocidad con un ratio cercano. Este caso ilustra que, sobre binarios muy grandes, las diferencias absolutas en GB pesan tanto como los minutos de CPU, y conviene cuantificar ambos.

4) ZIPs de juegos (EU4) y paso de tar+brotli a ZIP con ZSTD

Un caso real: saves de EU4 llegan como ZIPs poco comprimidos. Se probó extraer y recomprimir: rezip ahorra ~17%. Cambiando el códec dentro de ZIP, los números por nivel fueron:

Además, los payloads Wasm para transcodificar: ZSTD ~215 kB (136 kB si solo codificador), Brotli ~683 kB. En parsing, contando tiempo de fetch desde cache (el content-encoding brotli del navegador no es gratis), ZSTD y Brotli quedaron muy parejos: Brotli parsea algo más rápido por no descomprimir en user space; ZSTD se beneficia de no tocar el content-encoding y lee más ligero del disco.

Con subida de 30 Mb/s, integrando transcodificación + transferencia en un ZIP típico de 7,7 MB: original 2,05 s; ZSTD-3 1,70 s; ZSTD-5 1,88 s; ZSTD-7 2,28 s. La recomendación práctica se inclinó por ZSTD nivel 7 por ahorro de almacenamiento (cuando pagas tú el bucket), aunque nivel 3 es tentador si priorizas latencia.

5) Despliegues .NET (5,4 GB publish)

En un caso de despliegue de aplicaciones .NET con 5,4 GB de salida (mezcla self-contained y framework-dependent), la guía práctica es clara: elige por objetivo. Si apuntas a compatibilidad universal, tira de ZIP clásico; si el cuello de botella es descompresión y velocidad, ZSTD entra fuerte; si quieres ratio alto con CLI y tooling consolidado, 7Z con LZMA2 sigue siendo caballo ganador.

Descompresión: el factor que más se nota en la experiencia

Varias pruebas independientes señalan a ZSTD como clase aparte en descompresión. En el bench textual, al mirar user+sys se entiende por qué ZSTD es óptimo para la compresión del sistema de ficheros (ver cómo desactivar la compresión automática) y empaquetado de paquetes: la lectura es ágil y el coste CPU bajo. 7zip ofrece una experiencia muy buena, y la diferencia con XZ se explica más por utilidades y multihilo que por magia del códec.

ZIP dio la sorpresa en métricas user+sys de descompresión quedando menos mal de lo esperado; si tu público tiene máquinas modestas o workflows donde prima la extracción rápida, no lo descartes sin medir. ZPAQ, por su parte, vuelve a recordarnos su perfil: ratio increíble, pero tiempos de extracción muy altos, apto para copias frías.

Casos de uso: cómo decidir con datos (RAM, tiempo, ratio y coste)

En un escenario de plataforma de contenedores donde hay que hacer backups diarios de 30–100 contenedores, el presupuesto operativo manda. Se propuso un scoring pragmático:

• RAM: objetivo 200 MB en compresión y 100 MB en descompresión para puntuar 5; por cada +50 MB, resta 1 punto.
• Tiempo: ventana diaria de 3 horas para comprimir todo; por contenedor, 6–1,8 minutos. En la escala, >120 s puntúa 0, cada -20 s suma 1, <10 s es 5 puntos en descompresión.
• Ratio: con objetos de ~1,6 GB (p. ej. MariaDB+PHP+WordPress), y almacenamiento a ~6 $/TB en backends tipo Backblaze/E2, buscar ≥4:1 ayuda a bajar coste de egress (cuidado con AWS a 0,09 $/GB de salida).

Probando niveles, ZSTD nivel 3 logró ~3,5:1 en ~3 s con 207 MB de RAM; Brotli nivel 6 alcanzó ~4,3:1 en ~30 s con buen perfil de RAM. Ajustando tuning de ZSTD (estrategia, searchLog, targetLength, minMatch) no se mejoró lo suficiente sin penalizar tiempo o memoria; en ese análisis concreto, Brotli nivel 6 salió favorito. Curiosamente, Brotli nivel 4 usó más memoria que 3/5 pero igualó ratio de nivel 5 a la mitad de tiempo, una opción muy golosa si 13 MB extra de almacenamiento son asumibles.

Si cambia el objetivo (por ejemplo, despliegues rápidos o lectura intensiva), los pesos varían y ZSTD tiende a ser la elección más equilibrada por su decompresión fulgurante y ratios decentes a niveles medios.

Compatibilidad, soporte y el papel del ZIP con ZSTD

Algo clave: el estándar ZIP incorporó ZSTD (método 93) desde la especificación 6.3.8 (2020). Eso permite «ZIP de toda la vida» con un códec moderno. ¿Qué tal lo soporta el ecosistema? Hoy, Windows Explorer no crea ni extrae ZIP con ZSTD; 7-Zip principal lo está integrando, y hay forks ya operativos. En Linux, hay forks de p7zip. La situación mejora, pero aún hay fricciones.

Si usas Total Commander, puedes habilitar lectura 7z con ZSTD sustituyendo la TCLZMA64.DLL por versiones compatibles (p. ej. del paquete TotalCmd.7z de 7-Zip ZS). Para crear 7z con ZSTD dentro de TC, los plugins antiguos no siempre respetan el códec elegido y caen en LZMA; conviene usar 7-Zip ZS completo o el plugin Codecs en una instalación 7-Zip existente. Con 7-Zip ZS tendrás compresión/descarga de Brotli, LZ4, Lizard, ZSTD dentro del contenedor 7z y manejo de ZIP+ZSTD. Comprueba con 7z i qué códecs están activos.

En navegadores y pipelines web, el content-encoding de Brotli parece un «gratis total», pero hay matices: middleware, proxies y frameworks (p. ej. discrepancias entre modo debug/producción en Next.js) pueden rehacer la compresión o añadir latencia. Servir precomprimidos tampoco es siempre sencillo (Cloudflare Pages no lo soporta de serie). En varios casos reales, sustituir flujos con ZSTD en ZIP y descompresión en user space aportó menos dependencias del entorno y resultados equivalentes o mejores.

Parámetros útiles y niveles recomendados

En ZSTD, los niveles 3, 5 y 7 ofrecen buenos puntos de operación. Un estudio cruzando transcodificación+transferencia con 30 Mb/s mostró nivel 3 como el más rápido extremo a extremo, pero nivel 7 ahorraba almacenamiento (en EU4, 12,5% menos que 5 y 25% menos que 3). AWS Athena documenta preferencias por niveles 6–9 cuando no se usa el 3 por defecto, lo que encaja con ese hallazgo.

La tentación de activar long-distance matching es real, pero ojo: exigirás que quien descomprima disponga de la misma memoria que quien comprimió. En despliegues y apps cliente, ese requisito puede ser inviable. Mejor mantener ventanas y tablas dentro de presupuestos razonables.

En Brotli, el ajuste estrella suele ser el nivel. Cambiar lgwin puede aumentar memoria sin grandes ganancias si ya vas alto. La observación de que nivel 4 iguala ratio de 5 a mitad de tiempo —a costa de algo más de RAM— es oro cuando quieres bajar latencia sin castigar demasiado el tamaño.

Para XZ, el flag -e aplica variantes más lentas del preset buscando un pelín más de ratio. Las tablas de manual recuerdan que la memoria del compresor sube, pero la del descompresor se mantiene. Aun así, frente a ZSTD, XZ suele perder en decompresión cuando lo que quieres es abrir paquetes a gran velocidad.

Si dependes de ZIP clásico pero quieres la máxima velocidad de Deflate, librerías como libdeflate mejoran mucho el throughput frente a zlib. En el ecosistema Rust, zip-rs no facilita aún cambiar backends al crear ZIPs, por lo que esa vía puede no estar disponible sin trabajo adicional.

Artículo relacionado:

Cómo acelerar la transferencia de archivos en Windows 11: trucos y ajustes clave

Isaac

Redactor apasionado del mundo de los bytes y la tecnología en general. Me encanta compartir mis conocimientos a través de la escritura, y eso es lo que haré en este blog, mostrarte todo lo más interesante sobre gadgets, software, hardware, tendencias tecnológicas, y más. Mi objetivo es ayudarte a navegar por el mundo digital de forma sencilla y entretenida.