localStorage vs sessionStorage vs Cookies: un confronto dettagliato

I cookie sono stati con noi per molto tempo (Internet Explorer v2 li supportava nell'ottobre 1995). Non c'è niente di sbagliato in loro, e sicuramente hanno reso il web un posto più piacevole, ma dopo quasi 25 anni molto è cambiato.

L'archiviazione locale (lo troverai in Archiviazione Web su W3) è e non è un sostituto dei cookie. Questo è ciò che più confonde. Nella maggior parte dei casi, puoi tranquillamente utilizzare localStorage invece dei cookie e avere l'impressione (errata) che siano gli stessi, mentre non lo sono. Continua a leggere per vedere una ripartizione senza fronzoli di come e quando utilizzare localStorage per sostituire i cookie.

Rivoluzione o evoluzione?

Archiviazione locale, o localStorage, o archiviazione DOM o archiviazione web (non sto inventando questi nomi; sono tutti in uso e tutti fanno riferimento alla stessa cosa) ha ottenuto l'adozione nel mondo reale tra i browser più diffusi nel 2012 come "HTML5 caratteristica". Sembrava una manna dal cielo per sostituire i biscotti. Una correzione per le richieste gonfie che trasportano dati non necessari con tutti i limiti di tempo e dimensioni. Sebbene "risolva" questi problemi, non è un sostituto delle mele per i biscotti.

E mentre siamo in tema di dati non necessari. Sapevi che le richieste non sono l'unica cosa che può avere un rigonfiamento non necessario, anche il tuo sito può. Fortunatamente, c'è una soluzione e si chiama WP Reset.

WP Reset è un plug-in che viene fornito con una gamma di opzioni di ripristino che ti consentiranno di eseguire operazioni come rimuovere i dati accumulati e/o componenti aggiuntivi (plugin, temi, utenti, widget, contenuti, ecc.) dal tuo sito e anche ripulendo l'intero sito. Incredibile, vero? Ma non è tutto. Tra le altre funzionalità, questo plug-in può creare snapshot di database, nonché raccolte di plug-in e temi che puoi installare con un clic tutte le volte che è necessario. Sicuramente uno strumento da provare.

Ma, ora, torniamo a parlare di localStorage.

Come suggerisce il nome, i dati vengono archiviati localmente, sul dispositivo dell'utente. Quindi non deve essere trasferito sulla rete con ogni richiesta HTTP riducendo l'ingombro e dandoci molto più spazio per salvare i dati. Quel paradigma "solo locale" è la differenza più significativa tra cookie e archiviazione locale. I cookie possono essere letti sia lato server che lato client, archiviazione locale solo lato client. Questo è tutto ciò che c'è da fare. Se la tua app dipende fortemente dalla lettura dei cookie lato server e dalla generazione di contenuti basati su di essa, passare all'archiviazione locale significherà riscrivere l'app. Se utilizzi i cookie solo per memorizzare impostazioni come la scheda attiva nell'interfaccia, l'archiviazione locale è un sostituto ideale.

Ingannevolmente simile

La tabella seguente fornisce una visione chiara delle differenze e dei casi d'uso di cookie, localStorage e sessionStorage. Mentre puoi dare un'occhiata rapidamente per ottenere la risposta di cui hai bisogno e andartene, ti consiglio di leggere le note a piè di pagina un po 'lunghe che entrano in maggiori dettagli. Sì, lo so che sei impegnato e vuoi vedere il prossimo video del gatto, ma le cose non sono in bianco e nero, quindi scavare un po' più a fondo ti farà bene.

Scavare più a fondo nel web storage e nei cookie

La quantità massima di dati che puoi memorizzare localmente dipende dal browser. Non ci sono garanzie e se vuoi una scommessa sicura, vai sotto i 5 MB, a circa 2 MB. Usa questo pratico strumento per testare la dimensione massima di archiviazione locale consentita nel tuo browser.

È uno scenario comune per gli utenti bloccare i cookie di terze parti o tutti i cookie . La stessa regola si applica all'archiviazione locale. Non ci sono garanzie e la tua app deve funzionare (o almeno non interrompersi) in un ambiente in cui l'archiviazione locale non è disponibile.

Tutti i cookie scadono ad un certo punto, ma le persone tendono a impostare la durata di alcuni anni che sembra per sempre nel tempo di Internet. La memoria locale, invece, non scade mai ed è disponibile fino a quando l'app o l'utente non la eliminano. L'archiviazione della sessione viene eliminata quando la scheda o la finestra vengono chiuse, senza eccezioni.

“Cosa vuoi dire che solo le stringhe possono essere salvate ? Salvo oggetti tutto il tempo!” JSON ti consente di salvare oggetti e altri tipi di dati sotto forma di stringa. La conversione avviene leggendo e scrivendo a tua insaputa. Con una libreria di suoni per gestire i cookie e l'archiviazione locale, non dovrai pensare ai tipi di dati. Tuttavia, ciò non cambia il fatto che solo le stringhe sono supportate in modo nativo.

Non esiste una singola funzionalità lato client supportata da tutti i browser . È un fatto triste, ma pur sempre un dato di fatto. Puoi controllare numeri specifici su Can I Use, ma per quanto riguarda i cookie e l'archiviazione locale, ignorerei tutti i browser che non li supportano. Sono marginali e inferiori all'1%.

Non è possibile accedere a localStorage solo tramite l'elaborazione lato server. Anche tu hai bisogno di JS. Quando l'utente richiede una pagina e PHP si attiva (o qualsiasi lingua lato server che utilizzi) per generarla, non avrai accesso a dati locali, sessioni o permanenti. Una volta caricata la pagina e avviato JS, puoi accedere ai dati locali e fare tutto ciò di cui hai bisogno: regolare l'interfaccia utente o utilizzare AJAX per inviare i dati locali al server. Quindi sì, puoi riportare i dati locali sul server ma non nello stesso modo e nello stesso momento in cui faresti con un cookie. A seconda delle tue esigenze, questo potrebbe essere un problema quando si tratta di passare dai cookie all'archiviazione locale, quindi, per favore, pianifica in anticipo!

Con l'archiviazione locale, nessun dato viene trasferito tra il client e il server (a meno che non sia presente un codice che lo fa esplicitamente). È ottimo per ridurre le dimensioni del carico utile. I cookie, invece, vengono trasferiti come campo di intestazione HTTP ad ogni richiesta sul dominio impostato. Non può essere modificato o disattivato selettivamente.

Gli utenti "non dovrebbero" accedere ai dati locali e modificarli direttamente (all'esterno dell'app), ma nulla impedisce loro di farlo. Sono disponibili numerosi strumenti di debug per la modifica dei dati archiviati localmente. Quindi non fidarti dei dati locali o presumere che l'utente non li abbia toccati. Dai sempre per scontato il peggio.

Sebbene i cookie abbiano un attributo "sicuro" che puoi impostare, questo non protegge il cookie in transito dall'applicazione al browser. Quindi è meglio di niente ma tutt'altro che sicuro. L'archiviazione locale, essendo una tecnologia solo lato client, non sa o si preoccupa se usi HTTP o HTTPS. La sicurezza deve venire dal modo in cui gestisci i dati. Non archiviare dati sensibili come numeri di carte di credito o password in nessuna forma di archiviazione locale! Mai!

Un po' di codice per iniziare

Questo articolo non vuole essere un tutorial di archiviazione Web JavaScript, ma per risparmiarti il ​​problema ecco un esempio Hello World con archiviazione locale;

// store a value
localStorage.setItem( 'name', 'John' );

// retrieve a value
localStorage.getItem( 'name' );

// remove the value
localStorage.removeItem( 'name' );

// only string values can be stored so for objects, use JSON
var post = {
  title: 'Cookies are old',
  author: 'Gordan'
}
localStorage.setItem( 'post', JSON.stringify( post ) );

// and to retrieve
var post = JSON.parse( localStorage.getItem( 'post' ) );

Il codice sopra funziona ed è il più semplice possibile. Tuttavia, non consiglio di usarlo. Come per i cookie, nessuno utilizza document.cookies per interagire con essi. Ci sono piccole differenze tra browser da tenere in considerazione e, poiché memorizzano solo stringhe, è necessario stringere e analizzare con JSON ad ogni lettura e scrittura. Ecco perché utilizziamo piccole librerie per aiutarci a gestire i cookie come js-cookie. Lo stesso vale per l'archiviazione locale. Mettere un piccolo livello di astrazione tra il codice e l'API aiuterà a lungo termine. Consiglio store.js. È in circolazione da un po', si prende cura di sciocchezze e fallback cross-browser e ha persino utili plug-in che ne espandono le funzionalità. Se sei interessato ad alcune pratiche di codifica, crea la tua libreria e convertila in un plugin jQuery.

I cookie sono cattivi, giusto? Abbiamo bisogno di qualcosa di nuovo!

I cookie non sono male. Hanno servito il loro scopo per decenni e continueranno a farlo poiché lo stoccaggio locale non è un sostituto "mele per mele". I biscotti, tuttavia, mostrano segni di invecchiamento. A parte questo, anche alcune delle loro carenze di progettazione non scompariranno presto. Vale a dire “inquinare” ogni richiesta sul dominio con payload dei cookie e dimensioni massime ridotte del payload.

Inadeguati e vecchi o meno, i cookie sono qui per restare, quindi non pensare che l'archiviazione locale prenderà il controllo completamente a breve. Tuttavia, in alcuni casi d'uso, l'archiviazione locale è senza dubbio una scelta migliore.

Se hai (molti) dati da archiviare sul lato client che raramente vengono trasferiti al server e quei dati non contengono nulla di sensibile, inizia a utilizzare l'archiviazione locale ! È esattamente ciò per cui è stato creato. Creerai un'app più veloce rendendo tutte le richieste HTTP sul dominio più leggere e otterrai quella calda sensazione sfocata di usare qualcosa di nuovo.