Il tuo carrello svuota al refresh, l'utente viene sloggato a metà navigazione o, peggio, i dati sensibili finiscono in un cookie leggibile da chiunque. Se sviluppi applicazioni web, questi problemi hanno una radice comune: stai usando lo strumento di storage sbagliato nel browser. Noi, di Meteora Web, dopo anni a costruire piattaforme proprietarie e a rimettere in sesto progetti ereditati, abbiamo visto ogni combinazione possibile di errori con Local Storage, Session Storage e Cookie. Questa guida ti dà il criterio di scelta definitivo, con esempi pratici, limiti reali e codice che puoi copiare subito.
Come funziona Local Storage rispetto a Session Storage e Cookie?
Partiamo dal perché. Il browser mette a disposizione tre modi per salvare dati lato client, e ognuno ha una vita, una portata e un livello di sicurezza diversi. Confonderli significa introdurre bug sottili che si manifestano solo in produzione, con utenti reali.
Local Storage è come un cassetto: i dati restano lì finché non li rimuovi tu o l'utente cancella i dati di navigazione. Sopravvive alla chiusura del browser e del computer. Session Storage è come una lavagna a fogli mobili: i dati vivono finché dura la scheda (tab). Chiudi la scheda, e tutto sparisce. Cookie sono i veterani: nati nel 1994, viaggiano avanti e indietro con ogni richiesta HTTP, hanno una scadenza che puoi controllare e un attributo HttpOnly che li rende invisibili a JavaScript.
La differenza pratica più importante? La capacità e il traffico. Local e Session Storage offrono circa 5-10 MB per dominio, mentre un cookie può contenere al massimo 4 KB. Ma il vero costo dei cookie è nascosto: ogni richiesta al server li include, rallentando il caricamento se ne accumuli troppi. Lo vediamo spesso nei progetti che ci arrivano: siti con 30 cookie da 2 KB ciascuno che appesantiscono ogni singola chiamata API.
Sponsored Protocol
// Verifica la capacità disponibile
function storageDisponibile(tipo) {
try {
const storage = tipo === 'local' ? localStorage : sessionStorage;
const test = '__test__';
storage.setItem(test, test);
storage.removeItem(test);
return true;
} catch (e) {
return false;
}
}
console.log('Local Storage disponibile:', storageDisponibile('local'));
console.log('Session Storage disponibile:', storageDisponibile('session'));Quale storage scegliere per i dati utente?
Se devi salvare una preferenza di tema (chiaro/scuro), un carrello abbandonato o una bozza di modulo, Local Storage è la scelta giusta. I dati devono sopravvivere alla sessione perché l'utente possa ritrovare tutto al prossimo accesso. Session Storage invece è perfetto per dati temporanei come lo stato di un wizard multi-step o un token di navigazione che non deve superare la chiusura della scheda.
Per i cookie, il discorso cambia: usali solo per ciò che il server deve leggere a ogni richiesta, come un identificativo di sessione (con HttpOnly) o un token di autenticazione sicuro. Mai per dati voluminosi o non essenziali.
Quale storage offre più sicurezza per i dati sensibili?
Nessuno dei tre è un caveau. Ma c'è una gerarchia di rischio che devi conoscere. Local Storage e Session Storage sono accessibili da qualsiasi script JavaScript eseguito nella pagina. Una vulnerabilità XSS (Cross-Site Scripting) e un attaccante legge tutti i token che ci hai salvato. I cookie, se impostati con HttpOnly, sono al riparo da questo specifico attacco perché JavaScript non può nemmeno leggerli.
La nostra posizione è netta: mai token di autenticazione o dati personali in Local Storage. Lo ripetiamo a ogni cliente che ci mostra un JWT salvato lì. Se il tuo stack è Laravel o qualsiasi backend serio, usa cookie HttpOnly + Secure + SameSite per la sessione. Punto.
Sponsored Protocol
// Impostare un cookie sicuro lato server (esempio con header PHP)
setcookie(
'session_token',
$token,
[
'expires' => time() + 3600,
'path' => '/',
'secure' => true, // Solo HTTPS
'httponly' => true, // Invisibile a JavaScript
'samesite' => 'Lax' // Protezione CSRF base
]
);Come gestire la scadenza e la pulizia dei dati nello storage del browser?
Local Storage non ha scadenza. Se salvi una bozza nel 2026, quella bozza è ancora lì nel 2030. Questo è un problema se non prevedi un meccanismo di pulizia. La nostra regola: ogni dato salvato deve avere una data di scadenza implicita o esplicita. Per Session Storage il problema non si pone, ma per Local Storage devi essere proattivo.
Un pattern che usiamo spesso è salvare un timestamp insieme al dato e validarlo alla lettura. Se il dato è vecchio, lo rimuovi e tratti il caso come se non esistesse. Semplice, efficace, senza librerie esterne.
// Salvare un dato con scadenza
function salvaConScadenza(chiave, valore, oreValide) {
const record = {
valore: valore,
scadenza: Date.now() + (oreValide * 3600 * 1000)
};
localStorage.setItem(chiave, JSON.stringify(record));
}
// Leggere un dato validando la scadenza
function leggiConScadenza(chiave) {
const raw = localStorage.getItem(chiave);
if (!raw) return null;
const record = JSON.parse(raw);
if (Date.now() > record.scadenza) {
localStorage.removeItem(chiave);
return null;
}
return record.valore;
}
salvaConScadenza('bozza_articolo', 'Contenuto...', 24);
console.log(leggiConScadenza('bozza_articolo'));Come pulire i dati di Session Storage alla chiusura della scheda?
Session Storage fa pulizia da solo: chiudi la tab, e i dati spariscono. Ma attenzione a un dettaglio: duplicare una scheda copia anche la Session Storage. Se la tua logica si basa su dati unici per tab, verifica di gestire questo caso. Un evento storage non scatta per modifiche nella stessa scheda, quindi se hai più tab aperte sullo stesso dominio, ogni tab ha la sua copia isolata.
Sponsored Protocol
Quale storage usare per il carrello e-commerce e le preferenze utente?
Qui entriamo nel nostro territorio. Abbiamo gestito il sistema ERP di un negozio di abbigliamento dall'interno — marginalità, magazzino, season. E abbiamo costruito e-commerce con WooCommerce e piattaforme custom. La domanda sul carrello è sempre la stessa: dove salvo i prodotti scelti prima del login?
La risposta dipende dal tuo modello di business. Se il carrello deve sopravvivere alla chiusura del browser (consigliato, riduce l'abbandono), usa Local Storage con un timestamp di scadenza (es. 7 giorni). Se il carrello è legato alla sessione di navigazione e vuoi spingere l'acquisto immediato, Session Storage va bene, ma accetti di perdere vendite da utenti che tornano dopo ore.
Le preferenze utente (lingua, valuta, tema) vanno in Local Storage. Sono dati a bassa sensibilità, devono persistere e non hanno bisogno del server. Per la lingua, però, valuta anche il cookie: se il server deve generare HTML nella lingua giusta al primo colpo, un cookie HttpOnly è più efficiente di un render lato client che lampeggia nella lingua sbagliata.
// Esempio: carrello in Local Storage con scadenza 7 giorni
const CARRELLO_KEY = 'carrello_meteora';
const SCADENZA_CARRELLO = 7 * 24 * 3600 * 1000; // 7 giorni in ms
function aggiungiAlCarrello(prodotto) {
const carrello = leggiConScadenza(CARRELLO_KEY) || [];
carrello.push(prodotto);
salvaConScadenza(CARRELLO_KEY, carrello, 168); // 168 ore = 7 giorni
}
function leggiCarrello() {
return leggiConScadenza(CARRELLO_KEY) || [];
}Come sincronizzare i dati tra tab diverse con lo storage del browser?
Hai due tab aperte: una sul catalogo, una sul carrello. L'utente aggiunge un prodotto nella prima tab. La seconda tab non lo vede. Questo è un problema classico di usabilità. La soluzione è l'evento storage, che il browser scatena quando un dato in Local Storage cambia in un'altra tab dello stesso dominio. Session Storage non attiva questo evento, quindi per la sincronizzazione tra tab devi usare Local Storage.
Sponsored Protocol
// Ascoltare i cambiamenti di storage da altre tab
window.addEventListener('storage', (event) => {
if (event.key === CARRELLO_KEY) {
const nuovoCarrello = event.newValue ? JSON.parse(event.newValue).valore : [];
aggiornaInterfacciaCarrello(nuovoCarrello);
}
});
function aggiornaInterfacciaCarrello(carrello) {
// Aggiorna il contatore e la lista nel DOM
document.getElementById('contatore-carrello').textContent = carrello.length;
}Come evitare conflitti di scrittura con Local Storage?
Il rischio con la sincronizzazione è la corsa critica: due tab scrivono nello stesso momento e una sovrascrive l'altra. La strategia pratica è leggere-modificare-scrivere come un'operazione atomica. In JavaScript puro non hai lock, ma puoi minimizzare il problema salvando l'intero stato in un unico oggetto e rileggendolo subito prima di ogni scrittura.
Quale storage scegliere per le prestazioni del sito?
La domanda che ci fanno sempre i clienti: il mio sito è lento, lo storage del browser c'entra qualcosa? Sì, eccome. I cookie viaggiano in ogni richiesta HTTP. Se hai 50 cookie da 2 KB, sono 100 KB di overhead per ogni pagina, immagine o chiamata API. Su una pagina con 100 risorse, sono 10 MB di traffico inutile. Local Storage e Session Storage, invece, non influenzano il traffico di rete: i dati restano nel browser e li leggi quando ti servono.
Sponsored Protocol
La nostra regola operativa: tutto ciò che non deve arrivare al server, non deve essere un cookie. Preferenze, bozze, cache di risposte API non sensibili, stato UI: tutto in Local o Session Storage. Cookie solo per autenticazione e tracciamento essenziale, e con dimensioni minime.
Cosa fare adesso
Ecco le azioni concrete da fare oggi sul tuo progetto:
1. Fai un audit dei tuoi cookie. Apri DevTools (F12) → Application → Cookies. Se vedi cookie non essenziali creati da JavaScript, spostali in Local Storage. Se vedi token di autenticazione in Local Storage, migrali a cookie HttpOnly.
2. Scegli lo storage giusto per ogni dato. Preferenze e bozze → Local Storage con scadenza. Stato temporaneo di una procedura guidata → Session Storage. Identificativo di sessione e token → Cookie HttpOnly + Secure + SameSite.
3. Implementa la scadenza dei dati. Usa il pattern salvaConScadenza e leggiConScadenza che trovi sopra. Non lasciare che i dati vivano per sempre.
4. Sincronizza le tab se serve. Se la tua app gestisce carrelli o stati condivisi, usa Local Storage e l'evento storage per mantenere le tab allineate.
5. Misura l'impatto dei cookie. Se il sito è lento, controlla il peso totale dei cookie. Ridurlo può essere più efficace di qualsiasi plugin di caching.
Se vuoi approfondire le basi del linguaggio, parti dalla nostra guida a JavaScript ES2024. E se hai un progetto con problemi di storage o prestazioni, sappiamo esattamente dove guardare: lo facciamo ogni giorno.
