Storage del browser: cosa, dove, perché

In parole semplici

Il browser ha molti modi di conservare dati. Sembra dettaglio tecnico finché un bug non rivela che “il dato non si salva” ma in realtà si salva nel posto sbagliato. Conoscere i contenitori risparmia ore di indagine sterile.

Parole nuove

• localStorage: chiave/valore stringa, persiste fino a cancellazione manuale.
• sessionStorage: chiave/valore stringa, persiste solo per la tab.
• cookie: piccolo dato inviato automaticamente con ogni richiesta HTTP.
• IndexedDB: database asincrono in-browser, capace di gigabyte.
• Cache API: cache di richieste/risposte HTTP, usata dai Service Worker.
• memory state: stato in variabili JavaScript; sparisce al refresh.

Cosa impari

• Scegliere il contenitore giusto per ogni tipo di dato.
• Aprire e leggere ogni contenitore in DevTools.
• Diagnosticare bug del tipo “il dato sembra perso” o “il dato vecchio non sparisce”.

La tabella dei contenitori

Contenitore	Vita	Dimensione	Sincrono?	Inviato al server?	Tipo di dati
memoria (variabili JS)	fino al refresh	RAM	sì	no	qualunque
sessionStorage	fino alla chiusura della tab	~5 MB	sì	no	stringhe
localStorage	fino a cancellazione manuale	~5 MB	sì	no	stringhe
cookie	fino a Expires	~4 KB ciascuno	sì	sì	stringhe
IndexedDB	fino a cancellazione manuale	centinaia di MB / GB	asincrono	no	strutturati (oggetti, blob)
Cache API	fino a cancellazione	grande	asincrono	no	request/response HTTP

Dove guardare in DevTools

Chrome/Edge: tab Application → pannelli “Local Storage”, “Session Storage”, “Cookies”, “IndexedDB”, “Cache Storage”.

Firefox: tab Storage.

Safari: tab Storage.

Tutti permettono di vedere, modificare, cancellare singoli valori.

Bug tipici per contenitore

localStorage

• “Il dato non c’è dopo refresh” → controlla che localStorage.setItem venga davvero chiamato e con quale chiave.
• “Il dato è una stringa strana” → localStorage salva solo stringhe. Per oggetti devi JSON.stringify in scrittura e JSON.parse in lettura.
• “Quota exceeded” → ~5 MB. Se superi, eccezione QuotaExceededError.

sessionStorage

• “Il dato c’era e adesso non c’è” → hai aperto nuova tab. sessionStorage è per-tab.

Cookie

• “Il cookie non parte con la richiesta” → SameSite, Secure, HttpOnly o Path non compatibili (modulo 8).
• “Il server vede un valore vecchio” → il cookie non è stato aggiornato; controlla Set-Cookie nella response.

IndexedDB

• “La transazione non si conclude” → IndexedDB è asincrono e basato su callback/promise. Una transazione si chiude appena lo stack svuota: se aspetti un await esterno, perdi la transazione.
• “Il database non si apre” → versione cambiata senza migrazione (onupgradeneeded).

Cache API / Service Worker

• “Vedo una vecchia versione del sito” → un Service Worker sta servendo la cache. Vedi prossima sezione.

Service Worker e cache aggressiva

Un Service Worker è uno script che intercetta le richieste della pagina. Spesso restituisce risposte dalla Cache API anziché contattare il server. Sintomi tipici:

• Modifichi il sito, ricarichi, vedi la vecchia versione.
• Network mostra (from ServiceWorker).
• “Hard reload” non aiuta.

Diagnosi:

1. DevTools → Application → Service Workers. Vedi i SW registrati.
2. Click su “Unregister” per quel SW.
3. Application → Cache Storage → svuota cache pertinente.
4. Ricarica.

Approfondimento nel modulo 7 (lezione su SW).

Quale contenitore per cosa

• Token di sessione: cookie (HttpOnly, Secure) — non leggibile da JS, sicuro contro XSS.
• Preferenze tema/lingua: localStorage — persiste sempre, non serve al server.
• Dato temporaneo della sessione corrente: sessionStorage — sparisce alla chiusura.
• Dati grandi e strutturati offline: IndexedDB.
• Cache asset / risposte: Cache API gestita da SW.

Scegliere il contenitore sbagliato è una delle cause più frequenti di bug “il dato non torna come mi aspetto”.

Esercizio guidato

Crea una piccola pagina con quattro pulsanti:

1. Salva una preferenza tema in localStorage.
2. Salva un contatore in sessionStorage.
3. Imposta un cookie con document.cookie.
4. Salva un oggetto strutturato in IndexedDB (anche solo via console o libreria idb).

Apri DevTools → Application. Verifica che ogni dato finisca nel posto giusto. Poi:

• Refresh: cosa rimane?
• Chiudi tab e riapri: cosa rimane?
• Apri nuova tab della stessa pagina: cosa è condiviso?

Errori frequenti del principiante

• “localStorage va in produzione tale e quale”. Sì, ma se cambi il formato del dato, gli utenti con dato vecchio si schiantano. Versiona la chiave.
• Salvare un oggetto in localStorage senza JSON.stringify. Diventa "[object Object]".
• Confondere sessionStorage e session cookie. Il primo non parte con la richiesta, il secondo sì.
• Ignorare il Service Worker. Se c’è, controlla sempre prima di altre indagini.