Cómo funciona el procesamiento local de archivos en un navegador
Si no se sube nada, ¿qué está haciendo el trabajo y dónde?
Qué significa aquí «local»
Un conversor en línea convencional es un sitio web con un punto de subida. Tu archivo se transmite a una máquina que no controlas, se procesa allí, se almacena durante un tiempo y se te ofrece de vuelta como descarga. El procesamiento local elimina la parte central de esa frase: el código que lee tu archivo se ejecuta dentro de la pestaña del navegador que ya tienes abierta, en tu propio procesador, y el resultado se escribe de vuelta en tu propio disco.
El sitio se sigue descargando por la red: el HTML, las hojas de estilo, los scripts y los módulos de WebAssembly llegan todos desde un servidor, como en cualquier página web. La diferencia está en la dirección. El código del programa baja; tu archivo no sube.
El navegador ya trae las piezas
| Función | Qué aporta |
|---|---|
| APIs File y Blob | Leer los bytes de un archivo que el usuario ha seleccionado o soltado, sin enviar un formulario |
| Web Workers | Ejecutar el trabajo pesado en un hilo de fondo para que la interfaz siga respondiendo |
| WebAssembly | Ejecutar bibliotecas de códecs compiladas de C, C++ o Rust a una velocidad cercana a la nativa |
| Canvas y OffscreenCanvas | Decodificar, dibujar, redimensionar y volver a codificar imágenes |
| WebCodecs | Llegar a los codificadores y decodificadores de vídeo acelerados por hardware del propio navegador |
| WebGPU | Ejecutar la inferencia de modelos y el trabajo paralelo sobre píxeles en el procesador gráfico |
| File System Access | Escribir el resultado directamente en la ubicación que elija el usuario, donde esté disponible |
Nada de esto es exótico. Es la misma plataforma que ejecuta hojas de cálculo, herramientas de diseño y juegos en una pestaña. La única decisión poco habitual es negarse a añadirle un servidor.
El camino que recorre un archivo
- Eliges un archivo. El navegador le pasa a la página un manejador, no una copia: una referencia.
- La página lee los primeros bytes para identificar el tipo real del archivo por su firma, en lugar de fiarse de la extensión.
- Estima cuánta memoria necesita el trabajo, y lo rechaza o lo pone en cola si eso supera lo que el dispositivo puede ofrecer con seguridad.
- Los bytes se transfieren a un Web Worker. Transferir un ArrayBuffer traslada su propiedad en vez de copiarlo, así que un archivo grande no existe dos veces en memoria.
- Dentro del worker, un códec de WebAssembly o una API de la plataforma hace la decodificación y la codificación de verdad.
- El resultado vuelve como bytes, se envuelve en un Blob y se te ofrece como descarga o se escribe en la ubicación que elijas.
- La URL temporal de ese Blob se revoca y los búferes se liberan.
Por qué WebAssembly es la pieza que lo cambió todo
Los códecs de imagen y de vídeo son décadas de C cuidadosamente optimizado. Reescribirlos en JavaScript nunca fue realista. WebAssembly es un formato binario de instrucciones portable que los navegadores ejecutan en un entorno aislado a una velocidad cercana a la del código nativo, lo que permite compilar esas bibliotecas ya existentes y enviarlas al navegador tal cual.
El aislamiento importa tanto como la velocidad. Un módulo de WebAssembly no tiene acceso ambiental a tu sistema de archivos, a tu red ni a tus otras pestañas. Ve la memoria que la página le entrega y nada más. Un códec malicioso, o simplemente con errores, no puede irse por ahí a leer algo que no se le ha dado.
Qué sigue tocando la red, y por qué no es tu archivo
Tres cosas llegan por la red: la página en sí, el motor de la herramienta que has abierto y —para el borrado de fondo— los pesos del modelo. Las tres son recursos estáticos propios de FileSlimmer, descargados desde el propio origen de FileSlimmer antes de que se lea ninguno de tus bytes. Son descargas, se pueden cachear y, después del primer uso, se pueden servir desde la caché del propio navegador sin red ninguna.
Todo lo que viene después de ese punto es local. Los motores reciben los bytes de los archivos solo a través de postMessage desde la página; nunca se les da una URL a la que enviar nada, y una política de seguridad de contenido restringe adónde podría conectarse la página aunque algún código lo intentara.
Los compromisos, dichos con claridad
| Aspecto | En tu navegador | En un servidor |
|---|---|---|
| Adónde va tu archivo | A ninguna parte | A una máquina que no controlas |
| Velocidad | La que dé tu dispositivo | La que haya pagado el operador |
| Archivos muy grandes | Limitados por la memoria del navegador | Limitados por los límites del operador |
| Funciona sin conexión | Sí, una vez cacheado el motor | No |
| Formatos exóticos | Solo lo que compile a WebAssembly | Cualquier cosa que instale el operador |
| Lote de mil archivos | Limitado por el dispositivo | Normalmente más adecuado |
El procesamiento local no es mejor en todos los casos. Es mejor cuando el archivo es privado, cuando el dispositivo da la talla y cuando el trabajo cabe en memoria. Un servidor es mejor cuando necesitas procesar mucho más de lo que una sola máquina puede contener. Tener claro en cuál de las dos situaciones estás es más útil que insistir en que un enfoque gana en todas partes.
Lo que esto no afirma
Esto es una afirmación sobre lo que hace esta aplicación. No es una afirmación sobre tus extensiones del navegador, que pueden leer el contenido de cualquier página que abras, ni sobre tu sistema operativo, que puede inspeccionar cualquier archivo que toques, ni sobre tu operador de red, que puede ver que has visitado un sitio. Eso queda fuera del alcance de cualquier sitio web, y una herramienta que te diga lo contrario está exagerando.
La afirmación es estrecha y comprobable: los archivos que seleccionas se procesan localmente en este navegador y FileSlimmer no los sube. La siguiente guía explica cómo comprobarlo por tu cuenta en vez de creértelo.
Herramientas para esta tarea
Fuentes
- W3C — File API
- W3C — WebAssembly Core Specification
- WHATWG — HTML Standard, Web Workers
- W3C — WebCodecs