Como funciona o processamento local de arquivos no navegador
Se nada é enviado, o que está fazendo o trabalho — e onde?
O que “local” significa aqui
Um conversor online convencional é um site com um endpoint de upload. Seu arquivo é transmitido para uma máquina que você não controla, processado lá, guardado por algum tempo e devolvido como download. O processamento local elimina o miolo dessa frase: o código que lê o seu arquivo roda dentro da aba do navegador que você já tem aberta, no seu próprio processador, e o resultado é gravado no seu próprio disco.
O site continua sendo baixado pela rede — HTML, folhas de estilo, scripts e módulos WebAssembly chegam todos de um servidor, como em qualquer página da web. A diferença está no sentido. O código do programa desce; o seu arquivo não sobe.
O navegador já traz as peças
| Recurso | O que ele oferece |
|---|---|
| APIs File e Blob | Ler os bytes de um arquivo que o usuário escolheu ou arrastou, sem envio de formulário |
| Web Workers | Rodar o trabalho pesado em uma thread de segundo plano, para a interface continuar respondendo |
| WebAssembly | Executar bibliotecas de codecs em C, C++ ou Rust compiladas, a uma velocidade próxima da nativa |
| Canvas e OffscreenCanvas | Decodificar, desenhar, redimensionar e recodificar imagens |
| WebCodecs | Acessar os codificadores e decodificadores de vídeo acelerados por hardware do próprio navegador |
| WebGPU | Rodar inferência de modelos e trabalho paralelo com pixels no processador gráfico |
| File System Access | Gravar o resultado direto no local que o usuário escolher, onde houver suporte |
Nada disso é exótico. É a mesma plataforma que roda planilhas, ferramentas de design e jogos dentro de uma aba. A única decisão incomum é se recusar a acrescentar um servidor a ela.
O caminho que um arquivo percorre
- Você escolhe um arquivo. O navegador entrega à página um identificador dele — não uma cópia, uma referência.
- A página lê os primeiros bytes para identificar o tipo real do arquivo pela assinatura, em vez de confiar na extensão.
- Ela estima quanta memória a tarefa exige e recusa ou enfileira o trabalho se isso passar do que o aparelho pode oferecer com segurança.
- Os bytes são transferidos para um Web Worker. Transferir um ArrayBuffer move a posse em vez de copiar, então um arquivo grande não existe duas vezes na memória.
- Dentro do worker, um codec em WebAssembly ou uma API da plataforma faz a decodificação e a codificação de fato.
- O resultado volta como bytes, é embrulhado em um Blob e é oferecido a você como download ou gravado no local que você escolher.
- A URL temporária desse Blob é revogada e os buffers são liberados.
Por que o WebAssembly foi o que mudou o jogo
Codecs de imagem e de vídeo são décadas de C cuidadosamente otimizado. Reescrevê-los em JavaScript nunca foi realista. O WebAssembly é um formato binário portátil de instruções que os navegadores executam em um sandbox a uma velocidade próxima da do código nativo, o que permite compilar essas bibliotecas já existentes e entregá-las ao navegador do jeito que estão.
O sandbox importa tanto quanto a velocidade. Um módulo WebAssembly não tem acesso automático ao seu sistema de arquivos, à sua rede nem às suas outras abas. Ele enxerga a memória que a página lhe entrega e nada mais. Um codec malicioso — ou simplesmente cheio de bugs — não consegue sair por aí lendo algo que não lhe foi dado.
O que ainda passa pela rede, e por que não é o seu arquivo
Três coisas chegam pela rede: a própria página, o motor da ferramenta que você abriu e — no caso da remoção de fundo — os pesos do modelo. Os três são arquivos estáticos do próprio FileSlimmer, buscados na origem do próprio FileSlimmer antes que qualquer byte seu seja lido. São downloads, podem ficar em cache e, depois do primeiro uso, são servidos pelo cache do próprio navegador, sem rede nenhuma.
Tudo depois desse ponto é local. Os motores recebem os bytes do arquivo apenas por postMessage vindo da página; eles nunca recebem uma URL para onde mandar nada, e uma política de segurança de conteúdo restringe para onde a página poderia se conectar mesmo que algum código tentasse.
As trocas, sem rodeios
| Aspecto | No seu navegador | Em um servidor |
|---|---|---|
| Para onde vai o seu arquivo | Para lugar nenhum | Para uma máquina que você não controla |
| Velocidade | O que o seu aparelho der conta | O que o operador pagou |
| Arquivos muito grandes | Limitados pela memória do navegador | Limitados pelo que o operador permite |
| Funciona offline | Sim, depois que o motor está em cache | Não |
| Formatos exóticos | Só o que compila para WebAssembly | Qualquer coisa que o operador instale |
| Lote de mil arquivos | Limitado pelo aparelho | Em geral mais adequado |
O processamento local não é melhor em todos os casos. Ele é melhor quando o arquivo é privado, quando o aparelho dá conta e quando o trabalho cabe na memória. Um servidor é melhor quando você precisa processar muito mais do que uma máquina consegue segurar. Ter clareza sobre em qual das duas situações você está é mais útil do que insistir que uma abordagem vence em todo lugar.
O que isto não afirma
Esta é uma afirmação sobre o que este aplicativo faz. Não é uma afirmação sobre as suas extensões de navegador, que conseguem ler o conteúdo de qualquer página que você abra, nem sobre o seu sistema operacional, que pode inspecionar qualquer arquivo que você toque, nem sobre a sua operadora de rede, que consegue ver que você visitou um site. Isso tudo está fora do alcance de qualquer site, e uma ferramenta que diga o contrário está exagerando.
A afirmação é estreita e verificável: os arquivos que você seleciona são processados localmente neste navegador e não são enviados pelo FileSlimmer. O próximo guia explica como conferir isso por conta própria, em vez de acreditar.
Ferramentas para isso
Fontes
- W3C — File API
- W3C — WebAssembly Core Specification
- WHATWG — HTML Standard, Web Workers
- W3C — WebCodecs