localStorage e sessionStorage a confronto

La Web Storage API fornisce due archivi client-side chiave-valore: localStorage (persistente tra le sessioni) e sessionStorage (cancellato alla chiusura della scheda). Entrambi memorizzano valori stringa e sono accessibili in modo sincrono tramite JavaScript dalla stessa origine.

I dati in localStorage persistono finché non vengono cancellati esplicitamente dal codice, dall'utente o tramite l'eliminazione dei dati del browser. Sopravvivono al riavvio del browser, all'aggiornamento della pagina e alla chiusura della scheda. La capacità è in genere di 5-10 MB per origine, a seconda del browser.

sessionStorage è associato alla scheda e alla sessione correnti del browser. I dati sopravvivono agli aggiornamenti della pagina nella stessa scheda, ma vengono cancellati quando la scheda viene chiusa. Due schede che visitano lo stesso sito hanno sessionStorage separati e isolati: non condividono i dati.

Entrambi gli archivi condividono la stessa API: setItem(key, value), getItem(key), removeItem(key), clear() e la proprietà length. Lo stesso codice funziona per entrambi: basta sostituire localStorage con sessionStorage e viceversa.

Utilizzi localStorage per: preferenze dell'utente (tema, lingua), risposte dell'API memorizzate nella cache e funzionalità «ricordami». Utilizzi sessionStorage per: lo stato dei passaggi di procedure guidate o moduli, un carrello temporaneo prima del checkout e i dati che, per motivi di privacy, non devono persistere tra visite diverse.

Entrambi gli archivi sono rigorosamente associati all'origine (protocollo + host + porta). https://example.com non può leggere il localStorage impostato da http://example.com. Questo costituisce un confine di sicurezza: anche i sottodomini sono origini separate, a meno che document.domain non venga modificato (operazione deprecata).

Nella maggior parte dei browser, entrambi hanno un limite di circa 5 MB per origine. Il superamento del limite genera un QuotaExceededError. Per memorizzare grandi quantità di dati è necessario IndexedDB, che supporta gigabyte di dati strutturati. La Web Storage è adatta a piccole coppie chiave-valore, non a blob binari o grandi dataset.

Le operazioni di lettura e scrittura della Web Storage sono sincrone e bloccano il thread principale. Per letture o scritture di grandi dimensioni, questo può causare rallentamenti visibili. Preferisca IndexedDB per le operazioni frequenti su grandi quantità di dati. Mantenga piccoli e poco frequenti i valori della Web Storage per evitare problemi di prestazioni.

La Web Storage memorizza solo stringhe. Serializzi gli oggetti con JSON.stringify() e li deserializzi con JSON.parse(). Gestisca gli errori di analisi: try { return JSON.parse(stored) } catch { return defaultValue }. Valori corrotti o non JSON presenti nello storage generano errori di analisi.

In modalità privata o in incognito, localStorage viene cancellato quando tutte le finestre private vengono chiuse, comportandosi quindi come sessionStorage. Il codice che si affida a localStorage per lo stato di autenticazione deve gestire il caso in cui localStorage venga cancellato inaspettatamente.

I browser limitano sempre più l'accesso allo storage di terze parti. Un iframe proveniente da third-party.com incluso in first-party.com non può accedere al localStorage di third-party.com. ITP di Safari e Enhanced Tracking Protection di Firefox compartimentano lo storage; l'utilizzo da parte della prima parte non è interessato.

Quando viene cancellato sessionStorage?

localStorage persiste indefinitamente finché non viene cancellato programmaticamente o dall'utente; sessionStorage viene cancellato alla chiusura della scheda. Entrambi sono archivi sincroni di stringhe chiave-valore associati all'origine, con una capacità di circa 5 MB. Utilizzi localStorage per le preferenze e lo stato persistente; utilizzi sessionStorage per lo stato temporaneo associato alla sessione, che non deve sopravvivere alla chiusura della scheda.