ToolBox Image — Perché abbiamo creato ToolBox Image per funzionare interamente nel tuo browser

La maggior parte degli strumenti gratuiti per immagini online funzionano allo stesso modo: carichi un file sul loro server, il server lo elabora e scarichi il risultato. Quel modello è semplice da costruire, ma comporta costi nascosti — la tua privacy, le loro fatture del server e limiti sulla dimensione dei file e sulla velocità effettiva.

ToolBox Image adotta un approccio diverso. L'intera applicazione — decodifica, codifica, compressione, ridimensionamento, conversione di formato — viene eseguita nel tuo browser. Non c'è un server a cui caricare i file. Le tue immagini non lasciano mai il tuo dispositivo. Questa architettura è stata una scelta deliberata e ha plasmato ogni decisione che abbiamo preso sul prodotto.

Perché l'approccio browser-first?

L'alternativa ovvia è un'architettura tradizionale lato server. Carichi un'immagine, il server la elabora con uno strumento come ImageMagick o Sharp e rimanda il risultato. Funziona, ma crea una serie di problemi difficili da risolvere:

• Privacy. Gli utenti devono fidarsi che non memorizzerai, analizzerai o divulgherai le loro immagini. Per documenti sensibili — immagini mediche, mockup di design, foto personali — quella fiducia è difficile da guadagnare.
• Costo. Ogni compressione viene eseguita sulla tua infrastruttura. Più successo hai, più paghi. Questo crea pressione per limitare le dimensioni dei file, aggiungere code o introdurre livelli a pagamento.
• Latenza. Caricare un file da 100 MB su una connessione lenta richiede minuti prima che l'elaborazione inizi. Per gli utenti in regioni con scarsa connettività, lo strumento è effettivamente inutilizzabile.
• Scalabilità. Un singolo server può gestire decine di compressioni simultanee. Ma cosa succede con migliaia? Hai bisogno di gruppi di auto-scaling, bilanciatori di carico, endpoint CDN — tutto ciò aggiunge complessità e costi.

Il modello browser-first risolve tutto questo in una volta. L'elaborazione è gratuita (cicli CPU dell'utente), privata (nessun dato lascia il dispositivo) e infinitamente scalabile (ogni utente porta il proprio hardware).

Come funziona: WebAssembly e Web Workers

Dieci anni fa, eseguire codec di immagini nel browser era impossibile. Oggi, WebAssembly ci permette di compilare librerie C e Rust direttamente in un formato che il browser può eseguire a velocità quasi nativa. Compiliamo mozJPEG di Mozilla, libwebp di Google e il codificatore AVIF libaom — tutti scritti in C — in WebAssembly. Il browser li esegue con la stessa efficienza di se fossero installati nativamente.

Ma la codifica a thread singolo è lenta per lotti grandi. È qui che entrano in gioco i Web Worker. Ogni worker viene eseguito su un core CPU separato, e generiamo tanti worker quanti sono i core del dispositivo. Su un laptop moderno con 8 core, ciò significa 8 immagini che si comprimono simultaneamente. Un lotto di 200 foto che richiederebbe minuti su un singolo thread si completa in secondi.

Cosa abbiamo sacrificato

L'approccio browser-first non è gratuito. Il compromesso più significativo è la memoria. La scheda del browser ha accesso alla RAM del dispositivo, ma una singola scheda che si blocca perché un'immagine ha superato la memoria disponibile è una brutta esperienza. Limitiamo i singoli file a 100 MB e le dimensioni dei lotti a 200 file per rimanere entro limiti sicuri.

Abbiamo anche sacrificato funzionalità lato server come archiviazione persistente, consegna di email e analisi. Non c'è un database di immagini compresse, nessuna newsletter, nessun monitoraggio di quali formati gli utenti preferiscono. Questo è filosoficamente coerente con la nostra posizione sulla privacy, ma significa che non possiamo offrire funzionalità come "compressioni recenti" o "impostazioni salvate tra sessioni".

Cosa c'è dopo

Il browser sta diventando un runtime legittimo per applicazioni sensibili alle prestazioni. Man mano che WebAssembly ottiene garbage collection, threading e supporto SIMD, più parti dello stack applicativo possono spostarsi lato client. Stiamo esplorando WebGPU per un'elaborazione dei pixel ancora più veloce e l'API File System Access per un'integrazione perfetta delle cartelle.

Per ora, il compressore è attivo e elabora migliaia di immagini al giorno — tutte rimanendo esattamente dove devono stare.