Como funciona a compressão de ficheiros no cliente (e porque é mais privada)

Quando comprime uma fotografia ou reduz um PDF na maioria dos sites, o seu ficheiro faz uma viagem de ida e volta: é carregado para um servidor, processado nalgum centro de dados e devolvem-lhe uma versão mais pequena. Funciona, mas significa que uma cópia do seu ficheiro privado vive brevemente num computador que não controla. O FileShrinking adota uma abordagem diferente: cada byte da compressão acontece dentro do separador do seu próprio navegador, e os seus ficheiros nunca saem do seu dispositivo. Este artigo explica exatamente como isso é possível, que tecnologias do navegador o tornam viável e os compromissos honestos que implica.

Duas formas de comprimir um ficheiro na web

O modelo tradicional é do lado do servidor. O seu navegador envia o ficheiro original pela rede; um backend que executa uma ferramenta como o ImageMagick ou o FFmpeg faz o trabalho pesado; o resultado é transmitido de volta. A máquina do utilizador mal se esforça, e o servidor pode ser enormemente potente. O custo são a privacidade e a confiança: os seus dados são transmitidos, ficam (ainda que temporariamente) no disco de outra pessoa, e tem de acreditar na palavra dela quanto ao que lhes acontece depois.

O modelo mais recente é do lado do cliente. Os mesmos algoritmos de compressão são executados diretamente no seu dispositivo, no navegador, sem qualquer passo de carregamento. Durante anos isto foi pouco prático: o JavaScript por si só era demasiado lento para executar um codec de imagem ou vídeo a sério a uma velocidade utilizável. Isso mudou quando os navegadores ganharam a capacidade de executar código compilado, quase nativo, na web. Hoje um portátil ou um telemóvel modernos conseguem fazer o trabalho que antes exigia um servidor, e o FileShrinking está construído inteiramente sobre este modelo.

WebAssembly: codecs reais a correr no navegador

A tecnologia que torna viável a compressão no cliente é o WebAssembly (frequentemente abreviado para Wasm). É um formato de instruções binárias compacto e de baixo nível que os navegadores conseguem executar a velocidades próximas do código nativo. De forma crucial, permite aos programadores pegar em codecs escritos em C, C++ ou Rust (e refinados ao longo de décadas) e compilá-los para correrem na web sem os reescrever em JavaScript.

É assim que os mesmos motores de compressão testados em batalha que encontraria em software profissional de desktop acabam num separador do navegador:

• MozJPEG para uma codificação JPEG de alta qualidade que extrai mais de cada kilobyte.
• OxiPNG para a otimização PNG sem perdas.
• libwebp e os codificadores AVIF para os formatos modernos WebP e AVIF.
• FFmpeg, compilado para WebAssembly, para transcodificar e reduzir vídeo.

Para uma referência técnica mais aprofundada, a documentação do WebAssembly da MDN é a fonte canónica sobre como o formato funciona e porque é rápido.

Web Workers: manter a página com boa resposta

A compressão é computacionalmente pesada. Se executasse uma transcodificação de vídeo na thread principal do navegador, toda a página congelaria: os botões deixariam de responder, o deslocamento daria solavancos e as barras de progresso bloqueariam. Para evitar isto, o FileShrinking executa o trabalho numa thread separada usando Web Workers.

Um Web Worker é um contexto de JavaScript em segundo plano que corre em paralelo com a interface do utilizador. A thread principal entrega o ficheiro (e o codec Wasm) ao worker, o worker processa a compressão e devolve o resultado terminado quando acaba. Entretanto, a interface mantém-se fluida e pode mostrar o progresso em tempo real. O guia da MDN sobre a utilização de Web Workers aborda em detalhe o modelo de passagem de mensagens. Os dados binários grandes podem ser movidos entre threads de forma eficiente através de objetos transferíveis, de modo que o ficheiro não tem de ser copiado byte a byte só para cruzar a fronteira entre threads.

Ler e descodificar ficheiros sem a rede

Antes de poder comprimir seja o que for, o navegador tem de ler o seu ficheiro para a memória e descodificá-lo. Isto apoia-se numa pequena família de APIs web padrão, nenhuma das quais envolve um servidor:

• As APIs File e Blob representam o ficheiro que seleciona ou arrasta. Expõem os bytes em bruto como um ArrayBuffer sobre o qual os codecs podem trabalhar diretamente, tudo em memória.
• createImageBitmap descodifica eficientemente uma imagem para uma forma pronta a processar, e pode fazê-lo fora da thread principal.
• OffscreenCanvas permite ao navegador desenhar, redimensionar e recodificar dados de imagem dentro de um worker, sem nunca tocar na página visível.

No conjunto, a cadeia de processamento tem este aspeto: larga um ficheiro, o navegador lê os seus bytes localmente, um worker descodifica-o, o codec Wasm recodifica-o com a qualidade que escolher e devolve-se-lhe um novo Blob para descarregar. Em momento algum o ficheiro viaja para qualquer lado. Se tiver curiosidade sobre as decisões de qualidade nesse passo de recodificação, o nosso guia sobre compressão com perdas versus sem perdas explica o que é realmente descartado e porquê.

Porque isto é genuinamente mais privado

O benefício de privacidade do modelo do lado do cliente não é um slogan de marketing: é uma consequência direta da arquitetura. Como o seu ficheiro só é lido para a memória local e recodificado no seu dispositivo:

• Nada é transmitido. Não há carregamento, por isso não existe nenhuma cópia do seu ficheiro em trânsito que possa ser intercetada nem nenhuma cópia em repouso num servidor que possa ser violada, vendida ou requerida judicialmente.
• Funciona offline. Assim que a página e os seus codecs Wasm estiverem carregados, pode desligar-se por completo da internet e as ferramentas continuam a funcionar. Essa é a prova mais simples de que não está a ocorrer qualquer carregamento: pode verificá-lo por si mesmo no separador de rede do seu navegador.
• Não há nada para reter. Quando fecha o separador, os dados do ficheiro desaparecem da memória. Não há registos de servidor que liguem os seus documentos à sua identidade.

E como o FileShrinking é totalmente de código aberto sob a licença MIT, não tem de aceitar estas afirmações por fé. Qualquer pessoa pode ler o código, confirmar que não existe um caminho de carregamento e verificar exatamente como se comporta a cadeia de compressão. A privacidade auditável é a mais sólida.

Os compromissos honestos

A compressão no cliente não é magia, e é justo sermos claros sobre onde o modelo de servidor ainda tem vantagens:

• Velocidade em trabalhos muito grandes. Um centro de dados pode dedicar muitos mais núcleos a um vídeo longo do que aqueles que o seu portátil tem. Para a maioria das imagens e dos clips curtos a diferença é impercetível, mas um vídeo de longa duração será mais lento no navegador do que numa quinta de servidores.
• Limites de memória. Tudo acontece na RAM do seu dispositivo. Os ficheiros extremamente grandes (por exemplo, um vídeo de vários gigabytes num telemóvel com pouca memória) podem chocar com os tetos de memória do navegador que um servidor não teria.
• Custo do primeiro carregamento. Os codecs Wasm têm de ser descarregados na primeira vez que usa uma ferramenta. Depois ficam em cache, de modo que as visitas seguintes são instantâneas, mas a primeira execução paga uma transferência única.

Para a esmagadora maioria das tarefas do dia a dia (otimizar fotografias para a web, recortar um PDF até ao tamanho de um e-mail, reduzir uma gravação de ecrã) estes compromissos valem largamente a pena, e obtém privacidade de graça.

Veja por si mesmo

A melhor forma de compreender a compressão no cliente é usá-la. Experimente o compressor de imagens, o compressor de vídeo ou o compressor de PDF, e depois abra as ferramentas de programador do seu navegador, observe o separador de rede e confirme que nada é carregado enquanto o seu ficheiro encolhe. Tudo corre localmente, o código está aberto para que qualquer pessoa o inspecione, e os seus ficheiros ficam exatamente onde pertencem: consigo.