localStorage vs sessionStorage vs Cookies - une comparaison détaillée

Les cookies sont avec nous depuis longtemps (Internet Explorer v2 les supportait en octobre 1995). Il n'y a rien de mal avec eux, et ils ont certainement fait du Web un endroit plus agréable, mais après près de 25 ans, beaucoup de choses ont changé.

Le stockage local (vous le trouverez sous Stockage Web sur W3) est et ne remplace pas les cookies. C'est ce qu'il y a de plus déroutant. Dans la plupart des cas, vous pouvez utiliser localStorage en toute sécurité au lieu de cookies et avoir la (fausse) impression qu'ils sont identiques, alors qu'ils ne le sont pas. Poursuivez votre lecture pour découvrir comment et quand utiliser localStorage pour remplacer les cookies.

Révolution ou évolution ?

Le stockage local, ou localStorage, ou le stockage DOM ou le stockage Web (je n'invente pas ces noms ; ils sont tous utilisés et font tous référence à la même chose) ont été adoptés dans le monde réel par les navigateurs populaires en 2012 en tant que "HTML5 fonctionnalité". Cela semblait être une aubaine pour remplacer les cookies. Un correctif pour les requêtes gonflées transportant des données inutiles tout le temps et les limitations de taille. Bien qu'il « résolve » ces problèmes, il ne s'agit pas d'un remplacement des pommes pour les pommes pour les cookies.

Et pendant que nous parlons de données inutiles. Saviez-vous que les requêtes ne sont pas la seule chose qui peut avoir un gonflement inutile, votre site peut aussi. Heureusement, il existe une solution, et elle s'appelle WP Reset.

WP Reset est un plugin qui est livré avec une gamme d'options de réinitialisation qui vous permettront de faire des choses telles que la suppression des données accumulées et/ou des modules complémentaires (plugins, thèmes, utilisateurs, widgets, contenu, etc.) de votre site, et même en essuyant tout votre site. Incroyable, non ? Mais ce n'est pas tout. Entre autres fonctionnalités, ce plugin peut créer des instantanés de base de données ainsi que des collections de plugins et de thèmes que vous pouvez installer en un clic autant de fois que nécessaire. Certainement un outil qui vaut le détour.

Mais, maintenant, revenons à parler de localStorage.

Comme son nom l'indique, les données sont stockées localement, sur l'appareil de l'utilisateur. Par conséquent, il n'est pas nécessaire de le transférer sur le réseau, chaque requête HTTP réduisant l'empreinte et nous donnant beaucoup plus d'espace pour enregistrer les données. Ce paradigme "local uniquement" est la différence la plus significative entre les cookies et le stockage local. Les cookies peuvent être lus à la fois côté serveur et côté client, le stockage local uniquement côté client. C'est tout ce qu'on peut en dire. Si votre application dépend fortement de la lecture des cookies côté serveur et de la génération de contenu basé sur ceux-ci, le passage au stockage local signifiera la réécriture de l'application. Si vous utilisez uniquement des cookies pour stocker des paramètres tels que l'onglet actif dans l'interface, le stockage local est un remplacement idéal.

Trompeusement similaire

Le tableau ci-dessous donne un aperçu clair des différences et des cas d'utilisation des cookies, localStorage et sessionStorage. Bien que vous puissiez rapidement y jeter un coup d'œil pour obtenir la réponse dont vous avez besoin et partir, je vous recommande de lire les notes de bas de page un peu longues qui donnent plus de détails. Oui, je sais que vous êtes occupé et que vous voulez voir la prochaine vidéo de chat, mais les choses ne sont pas en noir et blanc, alors creuser un peu plus profondément vous fera du bien.

Approfondir le stockage Web et les cookies

La quantité maximale de données que vous pouvez stocker localement dépend du navigateur. Il n'y a aucune garantie et si vous voulez une valeur sûre, passez en dessous de 5 Mo, à environ 2 Mo. Utilisez cet outil pratique pour tester la taille de stockage locale maximale autorisée dans votre navigateur.

C'est un scénario courant pour les utilisateurs de bloquer les cookies tiers ou tous les cookies . La même règle s'applique au stockage local. Il n'y a aucune garantie et votre application doit fonctionner (ou du moins ne pas tomber en panne) dans un environnement où le stockage local n'est pas disponible.

Tous les cookies expirent à un moment donné, mais les gens ont tendance à définir leur durée de vie sur quelques années, ce qui semble éternel dans le temps Internet. Le stockage local, en revanche, n'expire jamais et est disponible jusqu'à ce que l'application ou l'utilisateur le supprime. Le stockage de session est purgé lorsque l'onglet ou la fenêtre est fermé - sans exception.

"Comment voulez-vous dire que seules les chaînes peuvent être enregistrées ? Je sauve des objets tout le temps ! JSON vous permet d'enregistrer des objets et d'autres types de données sous la forme d'une chaîne. La conversion se fait à la lecture et à l'écriture à votre insu. Avec une bibliothèque de sons pour gérer les cookies et le stockage local, vous n'aurez pas à vous soucier des types de données. Cependant, cela ne change rien au fait que seules les chaînes sont prises en charge de manière native.

Il n'y a pas une seule fonctionnalité côté client prise en charge par tous les navigateurs . C'est un fait triste, mais toujours un fait. Vous pouvez rechercher des numéros spécifiques sur Puis-je utiliser, mais en ce qui concerne les cookies et le stockage local, j'ignorerais tous les navigateurs qui ne les prennent pas en charge. Ils sont marginaux et inférieurs à 1 %.

Vous ne pouvez pas accéder à localStorage via le traitement côté serveur uniquement. Vous avez besoin de JS aussi. Lorsque l'utilisateur demande une page et que PHP démarre (ou quel que soit le langage côté serveur que vous utilisez) pour la générer, vous n'aurez accès à aucune donnée locale, de session ou permanente. Une fois la page chargée et JS lancé, vous pouvez accéder aux données locales et faire tout ce dont vous avez besoin - ajuster l'interface utilisateur ou utiliser AJAX pour renvoyer les données locales au serveur. Alors oui, vous pouvez récupérer les données locales sur le serveur mais pas de la même manière et au même moment qu'avec un cookie. Selon vos besoins, cela peut être un facteur décisif lorsqu'il s'agit de passer des cookies au stockage local, alors, s'il vous plaît, planifiez à l'avance !

Avec le stockage local, aucune donnée n'est transférée entre le client et le serveur (à moins qu'il n'y ait un code qui le fasse explicitement). C'est idéal pour réduire la taille de la charge utile. Les cookies, en revanche, sont transférés sous forme de champ d'en-tête HTTP avec chaque requête sur le domaine défini. Cela ne peut pas être modifié ou désactivé de manière sélective.

Les utilisateurs « ne devraient pas » accéder aux données locales et les modifier directement (en dehors de votre application) mais rien ne les empêche de le faire. De nombreux outils de débogage sont disponibles pour modifier les données stockées localement. Ne vous fiez donc pas aux données locales et ne supposez pas que l'utilisateur n'y a pas touché. Présumez toujours le pire.

Bien que les cookies aient un attribut "sécurisé" que vous pouvez définir, cela ne protège pas le cookie en transit de l'application au navigateur. C'est donc mieux que rien mais loin d'être sécurisé. Le stockage local, étant une technologie côté client uniquement, ne sait pas ou ne se soucie pas si vous utilisez HTTP ou HTTPS. La sécurité doit provenir de la façon dont vous gérez les données. Ne stockez aucune donnée sensible telle que des numéros de carte de crédit ou des mots de passe sous quelque forme que ce soit de stockage local ! Déjà!

Un peu de code pour commencer

Cet article n'est pas censé être un didacticiel sur le stockage Web JavaScript, mais pour vous éviter les ennuis, voici un exemple Hello World avec un stockage local.

// 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' ) );

Le code ci-dessus fonctionne, et c'est aussi simple que possible. Cependant, je ne recommande pas de l'utiliser. Comme pour les cookies, personne n'utilise document.cookies pour interagir avec eux. Il y a des différences mineures entre les navigateurs à prendre en compte, et comme ils ne stockent que des chaînes, vous devez stringifier et analyser avec JSON à chaque lecture et écriture. C'est pourquoi nous utilisons de petites bibliothèques pour nous aider à gérer les cookies tels que js-cookie. Il en va de même pour le stockage local. Mettre une petite couche d'abstraction entre votre code et l'API aidera à long terme. Je recommande store.js. Il existe depuis un certain temps, prend en charge les bêtises et les replis entre navigateurs et possède même des plugins pratiques qui étendent ses fonctionnalités. Si vous êtes intéressé par une pratique de codage, créez votre propre bibliothèque et convertissez-la en un plugin jQuery.

Les cookies sont mauvais, non ? Nous avons besoin de quelque chose de nouveau !

Les cookies ne sont pas mauvais. Ils remplissent leur fonction depuis des décennies et continueront de le faire car le stockage local n'est pas un substitut « pommes pour pommes ». Les cookies montrent cependant des signes de vieillissement. En dehors de cela, certaines de leurs lacunes en matière de conception ne vont pas disparaître de sitôt non plus. À savoir "polluer" chaque requête sur le domaine avec une charge utile de cookie et une petite taille de charge utile maximale.

Inadéquats et anciens ou non, les cookies sont là pour rester, alors ne pensez pas que le stockage local prendra complètement le dessus de si tôt. Cependant, dans certains cas d'utilisation, le stockage local est sans aucun doute un meilleur choix.

Si vous avez (beaucoup) de données à stocker côté client qui sont rarement transférées vers le serveur et que ces données ne contiennent rien de sensible – commencez à utiliser le stockage local ! C'est précisément pour cela qu'il a été créé. Vous créerez une application plus rapide en allégeant toutes les requêtes HTTP sur le domaine et vous obtiendrez cette sensation floue et chaleureuse d'utiliser quelque chose de nouveau.