Squoosh CLI, imagemin, sharp o PiPic: chequeo 2026 de las CLI de compresión
Pregunta por ahí cómo comprimir imágenes desde la terminal y recibirás siempre
las mismas respuestas: la CLI de Squoosh, imagemin, sharp, o un codificador de
formato único como pngquant. La mayoría de esos consejos vienen de 2023 o
antes. Así que dedicamos una tarde a comprobarlos — 7 de agosto de 2026, un
portátil normal, macOS con Apple Silicon, Node 22.14, el LTS actual. Lo
instalamos todo desde cero y lo pasamos por una misma carpeta de prueba: un
PNG, un JPEG, un JPEG ya optimizado una vez, y doce bytes de texto plano
renombrados a broken.jpg. En las carpetas de imágenes reales siempre acaba
colándose algo raro.
Antes de ejecutar nada, las marcas de tiempo del propio registro de npm ya cuentan bastante:
@squoosh/cli 0.7.3 Jan 2023 "no longer maintained" imagemin 9.0.1 Mar 2025 imagemin-cli 8.0.0 May 2024 imagemin-mozjpeg 10.0.0 Dec 2021 imagemin-webp 8.0.0 Jan 2023 sharp 0.35.3 Jul 2026 sharp-cli 5.2.0 Jun 2025
La CLI de Squoosh se cayó antes de tocar la primera imagen
Empezamos por @squoosh/cli, porque es la que más recomienda la gente. Es la
prima de línea de comandos de Squoosh, la aplicación web de Google — la web es
estupenda y sigue mantenida. La CLI no. Su última versión salió en enero de
2023, y su propio readme lo dice: "Project no longer maintained." (Proyecto
sin mantenimiento.)
La instalación funciona. El comando arranca. Y en cuanto le pides que comprima
algo, muere en el acto — su cargador de WebAssembly intenta hacer fetch() de
una ruta de archivo local, y el Node de hoy se niega:
code: 'ERR_INVALID_URL', input: '…/@squoosh/lib/build/imagequant_node-a4aafbae.wasm' — exit 1
Probamos también la ruta JPEG. Mismo fallo, mismo sitio. Instala esta herramienta hoy y no podrá comprimir ni una sola imagen. Los tutoriales la siguen recomendando, y los modelos entrenados con esos tutoriales también. Nadie ha corregido el consejo, porque ya no queda nadie en casa.
imagemin hizo el trabajo, y luego mintió sobre el archivo de texto
imagemin causó mejor primera impresión. El paquete central publicó versión en marzo de 2025, y con nuestras imágenes reales sencillamente funcionó — tres archivos dentro, "3 images minified", listo.
Dos cosas nos incomodaron por el camino. La primera, la instalación. Cuatro
paquetes, cinco avisos de deprecated, y npm audit encontró 37
vulnerabilidades en el proyecto recién creado — 1 de ellas crítica. La razón
no es difícil de encontrar: la compresión de verdad vive en plugins por
formato, y los plugins son viejos. El de JPEG publicó por última vez en
diciembre de 2021, el de WebP en enero de 2023, y AVIF no tiene plugin oficial.
La segunda, el archivo falso:
- Minifying images 1 image minified — exit 0
Copió los doce bytes de texto a la carpeta de salida, intactos, y los contó como una imagen comprimida. Exit 0. Con los ojos lo pillas al momento. Un script no. Un agent que lee "1 image minified, exit 0" informa de que todo fue bien y pasa a la siguiente tarea.
A sharp no le pasa nada — esa es la trampa
sharp está en plena forma. Publicó versión en julio de 2026, lleva una década sosteniendo el procesamiento de imágenes en npm, y en mantenimiento gana a todo lo demás de esta lista sin despeinarse.
Pero sharp no comprime carpetas. Es una biblioteca; el script lo pones tú. Así que escribimos el script que escribe todo el mundo — unas pocas líneas, ajustes por defecto — y lo ejecutamos:
photo.jpg 88556 -> 38879 smaller photo-optimized.jpg 26659 -> 32050 LARGER — exit 0
El JPEG recién exportado se comprimió de maravilla. El ya optimizado volvió un 20% más grande, y nuestro script lo guardó igualmente, porque nunca le dijimos que no lo hiciera. No es un fallo de sharp. El número de calidad, qué archivos saltarse, qué hacer cuando la salida crece, cómo informar del resultado — sharp lo deja todo en manos de quien escribe el script, y quien escribe el script sueles ser tú a las seis de la tarde, o tu agent. Ese script improvisado lo describimos en Dale a tu agent de código un compresor de imágenes; esta vez lo vimos fallar en directo.
Un número que juega en nuestra contra
Merece decirse en voz alta: con los ajustes por defecto, el mozjpeg de imagemin produjo el JPEG más pequeño del día — 26.659 bytes frente a los 31.774 de pipic. Los niveles de calidad por defecto varían de una herramienta a otra, así que los bytes por sí solos no zanjan nada; haría falta una comparación de calidad visual, y no la hicimos. Esta prueba va de comportamiento, no de ranking de compresión. Pero no vamos a esconder el número que no nos favorece.
Ya puestos a ser justos: los codificadores clásicos de formato único —
pngquant, oxipng, cjpeg, cwebp, avifenc — son sólidos, y son lo que
todo lo anterior envuelve por dentro. Si vives en un solo formato, úsalos
tranquilamente (para AVIF, la página de AVIF explica cuándo
compensa). Cuatro formatos, eso sí, significan cuatro instalaciones, cuatro
dialectos de flags y un script envoltorio que ahora te toca mantener a ti.
La misma carpeta con pipic
Le dimos a la CLI de pipic el directorio idéntico, archivo corrupto incluido:
$ pipic ./img -o ./out --json # paths shortened
{"file":"…/img/broken.jpg","status":"error","before":12,"after":0,"saved":0,"error":"UPSTREAM_ERROR: Compression service error"}
{"file":"…/img/icon.png","status":"ok","before":13897,"after":7449,"saved":6448}
{"file":"…/img/photo-optimized.jpg","status":"skipped","before":26659,"after":26659,"saved":0,"error":"not smaller — copied as-is"}
{"file":"…/img/photo.jpg","status":"ok","before":88556,"after":31774,"saved":56782}
{"file":"…/img/photo.png","status":"ok","before":302850,"after":104288,"saved":198562}
— exit 1
Compáralo con los fallos de arriba, uno por uno. El archivo de texto vuelve
como error con su motivo, y la ejecución entera sale con código 1, así que
un script sabe que algo falló. El JPEG ya optimizado queda en skipped y se
conserva tal cual, con la razón incluida, en lugar de engordar un 20% en
silencio. Y cada imagen recibe su propia línea de JSON con bytes reales de
antes y después, sobre la que un script puede ramificar directamente.
El precio existe, así que aquí va sin rodeos. Todas las demás herramientas de este artículo corren en tu máquina. pipic es un servicio: los archivos se suben, se comprimen en memoria y se borran de inmediato — nunca se almacenan — pero salen de tu ordenador. La CLI requiere cuenta, con 100 imágenes al mes gratis y 5.000 por $9 en Pro. El compresor web sigue siendo gratuito, ilimitado y sin cuenta pase lo que pase. Y si tu regla es "las imágenes no salen de esta máquina", usa las herramientas locales — esa regla está por encima de todo lo demás que diga este artículo.
Lo que la cuenta te compra es el reverso de cada hallazgo anterior: ningún cargador de wasm pudriéndose, ningún kit de plugins que montar, ninguna decisión de calidad que improvisar, y una salida en la que tu automatización puede apoyarse de verdad.
También ejecutamos un benchmark separado con 12 entradas bajo licencia en PNG, JPEG, WebP y AVIF. Publicamos su método, las 72 ejecuciones, las medianas, el fallo conservado y las revisiones visuales. Ese conjunto compara PiPic Agent CLI 1.0.6 con sharp 0.35.3. La prueba de carpeta anterior estudia el comportamiento operativo y no establece una clasificación por tasa de compresión.
Haz tú mismo la prueba de la carpeta
El método completo cabe en una tarde, y no hace falta que te fíes de nuestros números. Primero mira si queda alguien en casa:
npm view @squoosh/cli time.modified
Después crea una carpeta con una imagen ya optimizada y un archivo corrupto dentro, y pasa por ella tu herramienta candidata. Las imágenes limpias se comprimen bien en todas partes; no te dirán nada. Los archivos raros son donde una herramienta enseña su criterio — y toda carpeta acaba teniendo archivos raros.
