Come funziona la compressione dei file lato client (e perché è più privata)

Quando comprimi una foto o riduci un PDF sulla maggior parte dei siti web, il tuo file compie un viaggio di andata e ritorno: viene caricato su un server, elaborato in un data center da qualche parte, e ti viene restituita una versione più piccola. Funziona, ma significa che una copia del tuo file privato vive per un breve momento su un computer che non controlli. FileShrinking adotta un approccio diverso: ogni byte della compressione avviene all’interno della scheda del tuo browser, e i tuoi file non lasciano mai il tuo dispositivo. Questo articolo spiega esattamente come ciò sia possibile, quali tecnologie del browser lo rendono possibile e gli onesti compromessi che ne derivano.

Due modi per comprimere un file sul web

Il modello tradizionale è lato server. Il tuo browser invia il file originale attraverso la rete; un backend che esegue uno strumento come ImageMagick o FFmpeg svolge il lavoro pesante; il risultato viene trasmesso indietro. La macchina dell’utente fatica appena, e il server può essere enormemente potente. Il prezzo sono la privacy e la fiducia: i tuoi dati vengono trasmessi, restano (anche solo temporaneamente) sul disco di qualcun altro, e devi fidarti della sua parola su cosa accade loro in seguito.

Il modello più recente è lato client. Gli stessi algoritmi di compressione vengono eseguiti direttamente sul tuo dispositivo, nel browser, senza alcun passaggio di caricamento. Per anni ciò è stato poco pratico: JavaScript da solo era troppo lento per eseguire un codec serio per immagini o video a una velocità utilizzabile. Le cose sono cambiate quando i browser hanno acquisito la capacità di eseguire codice compilato, quasi nativo, sul web. Oggi un portatile o uno smartphone moderni possono svolgere il lavoro che un tempo richiedeva un server, e FileShrinking è costruito interamente su questo modello.

WebAssembly: codec reali in esecuzione nel browser

La tecnologia che rende praticabile la compressione lato client è WebAssembly(spesso abbreviato in Wasm). È un formato di istruzioni binarie compatto e di basso livello che i browser possono eseguire a velocità prossime al codice nativo. In modo cruciale, consente agli sviluppatori di prendere codec scritti in C, C++ o Rust (e affinati nell’arco di decenni) e di compilarli affinché vengano eseguiti sul web senza riscriverli in JavaScript.

È così che gli stessi collaudati motori di compressione che troveresti in software professionale per desktop finiscono in una scheda del browser:

• MozJPEG per una codifica JPEG di alta qualità che spreme di più da ogni kilobyte.
• OxiPNGper l’ottimizzazione PNG senza perdite.
• libwebp e i codificatori AVIF per i moderni formati WebP e AVIF.
• FFmpeg, compilato in WebAssembly, per transcodificare e ridurre i video.

Per un riferimento tecnico più approfondito, la documentazione di WebAssembly di MDN è la fonte canonica su come funziona il formato e perché è veloce.

Web Workers: mantenere la pagina reattiva

La compressione è onerosa dal punto di vista computazionale. Se eseguissi una transcodifica video sul thread principale del browser, l’intera pagina si bloccherebbe: i pulsanti smetterebbero di rispondere, lo scorrimento sarebbe a scatti e le barre di avanzamento si bloccherebbero. Per evitarlo, FileShrinking esegue il lavoro su un thread separato usando i Web Workers.

Un Web Worker è un contesto JavaScript in background che viene eseguito in parallelo con l’interfaccia utente. Il thread principale consegna il file (e il codec Wasm) al worker, il worker elabora la compressione e restituisce il risultato finito quando ha terminato. Nel frattempo l’interfaccia rimane fluida e può mostrare l’avanzamento in tempo reale. La guida di MDN all’uso dei Web Workers illustra in dettaglio il modello di scambio dei messaggi. I dati binari di grandi dimensioni possono essere spostati tra i thread in modo efficiente mediante oggetti trasferibili, così il file non deve essere copiato byte per byte solo per attraversare il confine tra i thread.

Leggere e decodificare i file senza la rete

Prima di poter comprimere qualcosa, il browser deve leggere il tuo file in memoria e decodificarlo. Ciò si basa su una piccola famiglia di API web standard, nessuna delle quali coinvolge un server:

• Le API File e Blob rappresentano il file che selezioni o trascini. Espongono i byte grezzi come un ArrayBuffer su cui i codec possono lavorare direttamente, il tutto in memoria.
• createImageBitmapdecodifica in modo efficiente un’immagine in una forma pronta per l’elaborazione, e può farlo al di fuori del thread principale.
• OffscreenCanvasconsente al browser di disegnare, ridimensionare e ricodificare i dati delle immagini all’interno di un worker, senza mai toccare la pagina visibile.

Messi insieme, la pipeline ha questo aspetto: rilasci un file, il browser ne legge i byte localmente, un worker lo decodifica, il codec Wasm lo ricodifica con la qualità che scegli e ti viene restituito un nuovo Blob da scaricare. In nessun momento il file viaggia da nessuna parte. Se sei curioso riguardo alle scelte di qualità in quel passaggio di ricodifica, la nostra guida alla compressione con perdita rispetto a quella senza perdita spiega cosa viene effettivamente scartato e perché.

Perché questo è davvero più privato

Il vantaggio in termini di privacy del modello lato client non è uno slogan di marketing: è una conseguenza diretta dell’architettura. Poiché il tuo file viene letto solo nella memoria locale e ricodificato sul tuo dispositivo:

• Non viene trasmesso nulla.Non c’è alcun caricamento, quindi non c’è alcuna copia del tuo file in transito da intercettare né alcuna copia a riposo su un server che possa essere violata, venduta o richiesta dalle autorità.
• Funziona offline. Una volta che la pagina e i suoi codec Wasm si sono caricati, puoi disconnetterti completamente da internet e gli strumenti continuano a funzionare. Questa è la prova più semplice che non sta avvenendo alcun caricamento: puoi verificarlo tu stesso nella scheda di rete del tuo browser.
• Non c’è nulla da conservare. Quando chiudi la scheda, i dati del file scompaiono dalla memoria. Non ci sono registri del server che colleghino i tuoi documenti alla tua identità.

E poiché FileShrinking è completamente open source sotto licenza MIT, non devi accettare queste affermazioni sulla fiducia. Chiunque può leggere il codice, confermare che non esiste un percorso di caricamento e verificare esattamente come si comporta la pipeline di compressione. La privacy verificabile è la più solida.

Gli onesti compromessi

La compressione lato client non è magia, ed è giusto essere chiari su dove il modello server ha ancora dei vantaggi:

• Velocità sui lavori molto grandi. Un data center può dedicare a un video lungo molti più core di quanti ne abbia il tuo portatile. Per la maggior parte delle immagini e dei clip brevi la differenza è impercettibile, ma un video di lunga durata sarà più lento nel browser che su una server farm.
• Limiti di memoria. Tutto avviene nella RAM del tuo dispositivo. I file estremamente grandi (ad esempio, un video di diversi gigabyte su uno smartphone con poca memoria) possono scontrarsi con i limiti di memoria del browser che un server non avrebbe.
• Costo del primo caricamento. I codec Wasm devono essere scaricati la prima volta che usi uno strumento. In seguito restano nella cache, così le visite successive sono istantanee, ma la primissima esecuzione paga un download una tantum.

Per la stragrande maggioranza delle attività quotidiane (ottimizzare le foto per il web, ridurre un PDF alle dimensioni di un’email, rimpicciolire una registrazione dello schermo) questi compromessi valgono ampiamente la pena, e ottieni la privacy gratis.

Provalo tu stesso

Il modo migliore per capire la compressione lato client è usarla. Prova il compressore di immagini, il compressore di video o il compressore di PDF, poi apri gli strumenti per sviluppatori del tuo browser, osserva la scheda di rete e conferma che non viene caricato nulla mentre il tuo file si rimpicciolisce. Tutto viene eseguito localmente, il codice è aperto affinché chiunque possa ispezionarlo, e i tuoi file restano esattamente dove devono stare: con te.