Lo storage lato client è una componente fondamentale delle moderne applicazioni web. Con l’evoluzione delle Single Page Application e l'aumento delle funzionalità eseguite direttamente nel browser, la necessità di memorizzare dati in modo persistente, efficiente e sicuro è diventata sempre più centrale.
Dati di configurazione, preferenze utente, cache applicative, token temporanei e persino interi dataset possono oggi risiedere sul client. Non tutte le soluzioni di storage sono però equivalenti. LocalStorage, SessionStorage e IndexedDB rispondono a esigenze diverse e presentano caratteristiche tecniche profondamente differenti.
Scegliere lo strumento sbagliato può compromettere performance, sicurezza e affidabilità dell’applicazione.
Comprendere le differenze tra questi sistemi non significa solo sapere dove salvare un valore, ma capire come il browser gestisce la persistenza dei dati, quali limiti impone e quali scenari di utilizzo risultano più appropriati.
Il contesto dello storage nel browser
Il browser moderno non è più un semplice visualizzatore di documenti HTML, ma un vero e proprio runtime applicativo. Per supportare applicazioni complesse, la piattaforma web mette a disposizione diverse API di persistenza locale. Tutte operano all’interno di un perimetro di sicurezza chiamato origin, che combina protocollo, dominio e porta.
Ciò significa che ogni sito ha accesso esclusivo al proprio spazio di storage. Isolato da quello di altri siti.
Questo isolamento garantisce sicurezza ma introduce limiti precisi in termini di capacità, durata dei dati e modalità di accesso. A differenza di un database server-side, lo storage lato client è vincolato dalle politiche del browser, può essere eliminato dall’utente e non offre garanzie di persistenza a lungo termine.
Proprio per questo motivo è fondamentale comprendere quale API usare e per quali scopi.
LocalStorage: semplicità e persistenza
LocalStorage è probabilmente la forma di storage lato client più conosciuta e utilizzata. Espone un'API sincrona estremamente semplice basata su coppie chiave-valore. I dati salvati in LocalStorage persistono anche dopo la chiusura del browser e rimangono disponibili fino a quando non vengono cancellati dall'applicazione o dall'utente.
LocalStorage memorizza solo stringhe. Qualsiasi struttura complessa deve essere serializzata, tipicamente tramite JSON. Questa caratteristica rende LocalStorage adatto a salvare informazioni leggere come preferenze dell’utente, impostazioni di interfaccia o flag di stato.
La semplicità ha però un costo. L’API è sincrona e blocca il thread principale durante l’accesso ai dati. In applicazioni di piccole dimensioni questo non rappresenta un problema. In contesti più complessi o con grandi quantità di dati può causare rallentamenti, specialmente durante il rendering.
Un altro limite importante è la capacità. Anche se variabile in base al browser, lo spazio disponibile è generalmente limitato a pochi megabyte. LocalStorage non supporta poi operazioni di query, transazioni o strutture dati avanzate. È essenzialmente un dizionario persistente.
LocalStorage, inoltre, non è adatto a conservare dati sensibili. Le informazioni sono accessibili da qualsiasi script in esecuzione nella stessa origin e possono essere vulnerabili a attacchi XSS. Per questo motivo, memorizzare token di autenticazione persistenti in LocalStorage è una pratica sconsigliata.
SessionStorage: persistenza limitata al ciclo di vita della sessione
SessionStorage condivide molte caratteristiche con LocalStorage, inclusa l’API sincrona e la gestione di dati come stringhe. La differenza principale risiede nella durata dei dati. SessionStorage è legato alla singola sessione di navigazione e viene cancellato automaticamente quando la tab o la finestra del browser viene chiusa.
Questa caratteristica rende SessionStorage ideale per memorizzare informazioni temporanee che non devono sopravvivere alla sessione corrente. Esempi tipici includono stati di navigazione, dati intermedi di un form multi-step o flag utili solo durante una singola interazione dell'utente.
Un aspetto spesso trascurato è che SessionStorage è isolato non solo per origin, ma anche per tab. Aprire la stessa applicazione in due schede diverse comporta due spazi di SessionStorage separati. Questo comportamento può essere vantaggioso o problematico a seconda del caso d’uso.
Dal punto di vista delle performance e dei limiti SessionStorage condivide gli stessi vincoli di LocalStorage: accesso sincrono, capacità ridotta e assenza di strutture avanzate.
Anche qui valgono le stesse considerazioni di sicurezza: non è il luogo adatto per memorizzare informazioni sensibili.
IndexedDB: un database nel browser
IndexedDB rappresenta un salto concettuale significativo rispetto a LocalStorage e SessionStorage. Non si tratta più di un semplice storage chiave-valore, ma di un vero e proprio database NoSQL orientato agli oggetti. Progettato per gestire grandi quantità di dati strutturati direttamente nel browser.
A differenza delle altre API, IndexedDB è completamente asincrono. Le operazioni di lettura e scrittura non bloccano il thread principale, rendendolo adatto ad applicazioni complesse e data-intensive. IndexedDB supporta oggetti JavaScript, indici, transazioni e operazioni di ricerca avanzate, offrendo una flessibilità paragonabile a quella di un database locale.
Il modello di programmazione è però più complesso. L’API nativa è basata su eventi e callback risultando spesso verbosa e difficile da gestire. Per questo motivo molte applicazioni utilizzano librerie di astrazione che semplificano l'interazione con IndexedDB, rendendola più simile a quella di un database tradizionale.
Un altro vantaggio è la capacità di storage. IndexedDB può memorizzare decine o centinaia di megabyte, a seconda delle politiche del browser e del consenso dell'utente. Questo la rende ideale per cache offline, applicazioni progressive, editor complessi e gestione di dataset di grandi dimensioni.
IndexedDB condivide il modello di isolamento per origin. Anche se non elimina i rischi legati a XSS, la sua natura asincrona rende più semplice applicare strategie di accesso controllato ai dati.
Scegliere lo storage giusto in base al caso d’uso
La scelta tra LocalStorage, SessionStorage e IndexedDB non dovrebbe mai essere casuale. Ogni soluzione è ottimizzata per scenari specifici. LocalStorage è adatto a dati semplici e persistenti che non richiedono alte prestazioni o strutture complesse. SessionStorage è ideale per informazioni temporanee legate alla sessione corrente. IndexedDB è la scelta naturale per applicazioni complesse che necessitano di performance, capacità e flessibilità.
Un errore comune è utilizzare LocalStorage come soluzione universale per qualsiasi tipo di dato. Questo approccio può funzionare in fase di prototipo ma diventa un collo di bottiglia in applicazioni reali.
Allo stesso modo, adottare IndexedDB per dati banali introduce delle complessità inutili.
Storage e architettura delle applicazioni moderne
Nelle architetture frontend moderne, lo storage lato client è spesso utilizzato in combinazione con lo storage server-side. Cache locali, sincronizzazione offline, gestione dello stato e ottimizzazione delle chiamate di rete dipendono da una scelta consapevole delle API di persistenza.
Le Progressive Web App, in particolare, fanno largo uso di IndexedDB per garantire funzionalità offline e prestazioni elevate. In questi è una parte integrante dell'esperienza utente.
Conclusione
LocalStorage, SessionStorage e IndexedDB rispondono a esigenze diverse e presentano compromessi in termini di semplicità, persistenza, performance e sicurezza.
Comprendere il funzionamento interno di ciascuna API permette di progettare applicazioni più robuste, efficienti e scalabili. La scelta corretta non è mai assoluta, dipende dal tipo di dato, dalla sua durata, dal volume e dal contesto.
