Come funziona l'elaborazione locale dei file in un browser
Se non viene caricato niente, chi fa il lavoro e dove?
Che cosa significa qui «locale»
Un convertitore online tradizionale è un sito con un endpoint di caricamento. Il tuo file viene trasmesso a una macchina che non controlli, elaborato lì, conservato per un certo periodo e restituito come download. L'elaborazione locale elimina la parte centrale di quella frase: il codice che legge il tuo file gira dentro la scheda del browser che hai già aperto, sul tuo processore, e il risultato viene riscritto sul tuo disco.
Il sito viene comunque scaricato dalla rete: HTML, fogli di stile, script e moduli WebAssembly arrivano tutti da un server, come per qualsiasi pagina web. La differenza è la direzione. Il codice del programma scende; il tuo file non sale.
Il browser contiene già i pezzi
| Funzionalità | Cosa fornisce |
|---|---|
| API File e Blob | Leggere i byte di un file scelto o trascinato dall'utente, senza inviare un modulo |
| Web Workers | Eseguire il lavoro pesante su un thread in background, così l'interfaccia resta reattiva |
| WebAssembly | Eseguire librerie di codec compilate da C, C++ o Rust a velocità quasi nativa |
| Canvas e OffscreenCanvas | Decodificare, disegnare, ridimensionare e ricodificare immagini |
| WebCodecs | Raggiungere gli encoder e i decoder video con accelerazione hardware del browser |
| WebGPU | Eseguire l'inferenza dei modelli e il lavoro parallelo sui pixel nel processore grafico |
| File System Access | Scrivere il risultato direttamente in una posizione scelta dall'utente, dove è supportato |
Non c'è niente di esotico. È la stessa piattaforma che fa girare fogli di calcolo, strumenti di progettazione e giochi dentro una scheda. L'unica scelta insolita è rifiutarsi di aggiungerci un server.
Il percorso che compie un file
- Scegli un file. Il browser consegna alla pagina un handle: non una copia, un riferimento.
- La pagina legge i primi byte per riconoscere il tipo di file reale dalla sua firma, invece di fidarsi dell'estensione.
- Stima quanta memoria richiede il lavoro e lo rifiuta o lo mette in coda se supera ciò che il dispositivo può fornire in sicurezza.
- I byte vengono trasferiti in un Web Worker. Trasferire un ArrayBuffer ne sposta la proprietà invece di copiarlo, così un file grande non esiste due volte in memoria.
- Dentro il worker, un codec WebAssembly o un'API della piattaforma esegue la decodifica e la codifica vere e proprie.
- Il risultato torna sotto forma di byte, viene incapsulato in un Blob e ti viene offerto come download oppure scritto in una posizione che scegli tu.
- L'URL temporaneo di quel Blob viene revocato e i buffer vengono liberati.
Perché WebAssembly è la cosa che ha fatto la differenza
I codec per immagini e video sono decenni di C ottimizzato con cura. Riscriverli in JavaScript non è mai stato realistico. WebAssembly è un formato binario portabile di istruzioni che i browser eseguono in una sandbox a velocità vicina a quella del codice nativo, il che significa che quelle librerie esistenti possono essere compilate e spedite al browser così come sono.
La sandbox conta quanto la velocità. Un modulo WebAssembly non ha alcun accesso implicito al tuo file system, alla tua rete o alle tue altre schede. Vede la memoria che la pagina gli passa e nient'altro. Un codec malevolo, o semplicemente pieno di bug, non può andarsene in giro a leggere qualcosa che non gli è stato dato.
Cosa passa ancora dalla rete, e perché non è il tuo file
Dalla rete arrivano tre cose: la pagina stessa, il motore dello strumento che hai aperto e — per la rimozione dello sfondo — i pesi del modello. Tutte e tre sono risorse statiche di FileSlimmer, scaricate dall'origine di FileSlimmer prima che venga letto un solo byte dei tuoi file. Sono download, sono memorizzabili in cache e dopo il primo utilizzo possono essere serviti dalla cache del browser senza toccare la rete.
Tutto ciò che viene dopo è locale. I motori ricevono i byte dei file solo tramite postMessage dalla pagina; non ricevono mai un URL a cui inviare qualcosa, e una content security policy limita i punti a cui la pagina potrebbe collegarsi anche se del codice ci provasse.
I compromessi, detti chiaramente
| Aspetto | Nel tuo browser | Su un server |
|---|---|---|
| Dove finisce il tuo file | Da nessuna parte | Su una macchina che non controlli |
| Velocità | Quella che il tuo dispositivo riesce a dare | Quella che il gestore ha pagato |
| File molto grandi | Limitati dalla memoria del browser | Limitati dai vincoli del gestore |
| Funziona offline | Sì, una volta che il motore è in cache | No |
| Formati esotici | Solo ciò che si compila in WebAssembly | Tutto ciò che il gestore installa |
| Lotti da mille file | Vincolati dal dispositivo | Di solito più adatto |
L'elaborazione locale non è migliore in assoluto. È migliore quando il file è riservato, quando il dispositivo è capace e quando il lavoro entra in memoria. Un server è migliore quando devi elaborare molto più di quanto una sola macchina possa contenere. Avere chiaro in quale delle due situazioni ti trovi è più utile che insistere sul fatto che un approccio vinca ovunque.
Cosa non viene affermato qui
Questa è un'affermazione su ciò che fa questa applicazione. Non è un'affermazione sulle tue estensioni del browser, che possono leggere il contenuto di qualsiasi pagina apri, né sul tuo sistema operativo, che può ispezionare qualsiasi file tocchi, né sul tuo operatore di rete, che può vedere che hai visitato un sito. Tutto questo è fuori dalla portata di qualunque sito web, e uno strumento che ti dice il contrario sta esagerando.
L'affermazione è circoscritta e verificabile: i file che selezioni vengono elaborati in locale in questo browser e non vengono caricati da FileSlimmer. La guida successiva spiega come verificarlo di persona invece di crederci.
Strumenti utili
Fonti
- W3C — File API
- W3C — WebAssembly Core Specification
- WHATWG — HTML Standard, Web Workers
- W3C — WebCodecs