Cómo funciona la compresión de archivos en el cliente (y por qué es más privada)

Cuando comprimes una foto o reduces un PDF en la mayoría de los sitios web, tu archivo hace un viaje de ida y vuelta: se sube a un servidor, se procesa en algún centro de datos y se te devuelve una versión más pequeña. Funciona, pero significa que una copia de tu archivo privado vive brevemente en un ordenador que no controlas. FileShrinking adopta un enfoque distinto: cada byte de la compresión ocurre dentro de la pestaña de tu propio navegador, y tus archivos nunca salen de tu dispositivo. Este artículo explica exactamente cómo es posible, qué tecnologías del navegador lo hacen funcionar y las compensaciones honestas que implica.

Dos formas de comprimir un archivo en la web

El modelo tradicional es del lado del servidor. Tu navegador envía el archivo original por la red; un backend que ejecuta una herramienta como ImageMagick o FFmpeg hace el trabajo pesado; el resultado se transmite de vuelta. La máquina del usuario apenas se inmuta, y el servidor puede ser enormemente potente. El coste son la privacidad y la confianza: tus datos se transmiten, se quedan (aunque sea temporalmente) en el disco de otra persona, y tienes que creer su palabra sobre lo que ocurre con ellos después.

El modelo más reciente es del lado del cliente. Los mismos algoritmos de compresión se ejecutan directamente en tu dispositivo, en el navegador, sin ningún paso de subida. Durante años esto fue poco práctico: JavaScript por sí solo era demasiado lento para ejecutar un códec de imagen o vídeo serio a una velocidad utilizable. Eso cambió cuando los navegadores ganaron la capacidad de ejecutar código compilado, casi nativo, en la web. Hoy un portátil o un teléfono modernos pueden hacer el trabajo que antes requería un servidor, y FileShrinking está construido íntegramente sobre este modelo.

WebAssembly: códecs reales ejecutándose en el navegador

La tecnología que hace viable la compresión en el cliente es WebAssembly (a menudo abreviado como Wasm). Es un formato de instrucciones binarias compacto y de bajo nivel que los navegadores pueden ejecutar a velocidades cercanas al código nativo. De forma crucial, permite a los desarrolladores tomar códecs escritos en C, C++ o Rust (y refinados durante décadas) y compilarlos para que se ejecuten en la web sin reescribirlos en JavaScript.

Así es como los mismos motores de compresión probados que encontrarías en software profesional de escritorio acaban en una pestaña del navegador:

• MozJPEG para una codificación JPEG de alta calidad que exprime más de cada kilobyte.
• OxiPNG para la optimización PNG sin pérdidas.
• libwebp y los codificadores AVIF para los formatos modernos WebP y AVIF.
• FFmpeg, compilado a WebAssembly, para transcodificar y reducir vídeo.

Para una referencia técnica más profunda, la documentación de WebAssembly de MDN es la fuente canónica sobre cómo funciona el formato y por qué es rápido.

Web Workers: mantener la página con buena respuesta

La compresión es computacionalmente pesada. Si ejecutaras una transcodificación de vídeo en el hilo principal del navegador, toda la página se congelaría: los botones dejarían de responder, el desplazamiento daría tirones y las barras de progreso se bloquearían. Para evitarlo, FileShrinking ejecuta el trabajo en un hilo separado usando Web Workers.

Un Web Worker es un contexto de JavaScript en segundo plano que se ejecuta en paralelo con la interfaz de usuario. El hilo principal entrega el archivo (y el códec Wasm) al worker, el worker procesa la compresión y devuelve el resultado terminado cuando acaba. Mientras tanto, la interfaz permanece fluida y puede mostrar el progreso en tiempo real. La guía de MDN sobre el uso de Web Workers cubre en detalle el modelo de paso de mensajes. Los datos binarios grandes se pueden mover entre hilos de forma eficiente mediante objetos transferibles, de modo que el archivo no tiene que copiarse byte a byte solo para cruzar la frontera entre hilos.

Leer y decodificar archivos sin la red

Antes de poder comprimir nada, el navegador tiene que leer tu archivo en memoria y decodificarlo. Esto se apoya en una pequeña familia de APIs web estándar, ninguna de las cuales implica un servidor:

• Las APIs File y Blob representan el archivo que seleccionas o arrastras. Exponen los bytes en bruto como un ArrayBuffer sobre el que los códecs pueden trabajar directamente, todo en memoria.
• createImageBitmap decodifica eficientemente una imagen a una forma lista para procesar, y puede hacerlo fuera del hilo principal.
• OffscreenCanvas permite al navegador dibujar, redimensionar y recodificar datos de imagen dentro de un worker, sin tocar nunca la página visible.

En conjunto, la cadena de procesamiento tiene este aspecto: sueltas un archivo, el navegador lee sus bytes localmente, un worker lo decodifica, el códec Wasm lo recodifica con la calidad que elijas y se te devuelve un nuevo Blob para que lo descargues. En ningún momento el archivo viaja a ninguna parte. Si te interesan las decisiones de calidad en ese paso de recodificación, nuestra guía sobre compresión con pérdidas frente a sin pérdidas explica qué se descarta realmente y por qué.

Por qué esto es genuinamente más privado

El beneficio de privacidad del modelo del lado del cliente no es un eslogan de marketing: es una consecuencia directa de la arquitectura. Como tu archivo solo se lee en la memoria local y se recodifica en tu dispositivo:

• No se transmite nada. No hay subida, así que no hay ninguna copia de tu archivo en tránsito que interceptar ni ninguna copia en reposo en un servidor que pueda ser vulnerada, vendida o requerida judicialmente.
• Funciona sin conexión. Una vez que la página y sus códecs Wasm se han cargado, puedes desconectarte por completo de internet y las herramientas siguen funcionando. Esa es la prueba más sencilla de que no se está produciendo ninguna subida: puedes comprobarlo tú mismo en la pestaña de red de tu navegador.
• No hay nada que retener. Cuando cierras la pestaña, los datos del archivo desaparecen de la memoria. No hay registros de servidor que vinculen tus documentos con tu identidad.

Y como FileShrinking es totalmente de código abierto bajo la licencia MIT, no tienes que aceptar estas afirmaciones por fe. Cualquiera puede leer el código, confirmar que no existe una ruta de subida y verificar exactamente cómo se comporta la cadena de compresión. La privacidad auditable es la más sólida.

Las compensaciones honestas

La compresión en el cliente no es magia, y es justo ser claros sobre dónde el modelo de servidor todavía tiene ventajas:

• Velocidad en trabajos muy grandes. Un centro de datos puede dedicar muchos más núcleos a un vídeo largo de los que tiene tu portátil. Para la mayoría de las imágenes y los clips cortos la diferencia es imperceptible, pero un vídeo de larga duración será más lento en el navegador que en una granja de servidores.
• Límites de memoria. Todo ocurre en la RAM de tu dispositivo. Los archivos extremadamente grandes (por ejemplo, un vídeo de varios gigabytes en un teléfono con poca memoria) pueden chocar con los topes de memoria del navegador que un servidor no tendría.
• Coste de la primera carga. Los códecs Wasm tienen que descargarse la primera vez que usas una herramienta. Después se quedan en caché, de modo que las visitas posteriores son instantáneas, pero la primera ejecución paga una descarga única.

Para la inmensa mayoría de las tareas cotidianas (optimizar fotos para la web, recortar un PDF hasta el tamaño de un correo, reducir una grabación de pantalla) estas compensaciones merecen la pena con creces, y obtienes privacidad gratis.

Compruébalo tú mismo

La mejor manera de entender la compresión en el cliente es usarla. Prueba el compresor de imágenes, el compresor de vídeo o el compresor de PDF, y luego abre las herramientas de desarrollo de tu navegador, observa la pestaña de red y confirma que no se sube nada mientras tu archivo se encoge. Todo se ejecuta localmente, el código está abierto para que cualquiera lo inspeccione, y tus archivos se quedan exactamente donde corresponde: contigo.