Je me demandais, en fait, quels sont les cas d'usage les plus pertinents pour l'un ou l'autre. Par exemple, est-ce qu'il y a des types de données qui se prêtent mieux aux cookies, et d'autres au local storage ? Je pense notamment à la sécurité des données, la taille des données à stocker, la durée de conservation, etc. Si vous avez des exemples concrets, je suis preneur !
Salut, C'est une bonne question que tu poses là. En gros, faut voir les cookies et le local storage comme des outils différents avec leurs propres forces et faiblesses. C'est un peu comme choisir entre un tournevis et une clé à molette, ça dépend de ce que tu veux faire 🛠️. Pour la sécurité, c'est clair que ni l'un ni l'autre ne sont des coffres-forts. Faut jamais stocker des infos sensibles en clair (genre mots de passe). Après, les cookies ont l'avantage de pouvoir être marqués comme `HttpOnly`, ce qui empêche le JavaScript d'y accéder directement, réduisant le risque de XSS. Le local storage, lui, est plus vulnérable de ce point de vue. Niveau taille, c'est le local storage qui gagne haut la main. Les cookies, c'est limité à environ 4KB par domaine (et encore, ça dépend des navigateurs). Le local storage, c'est plutôt de l'ordre de 5 à 10MB, ce qui laisse plus de marge pour stocker des données un peu plus conséquentes 💾. La durée de conservation, c'est toi qui la fixes dans les deux cas. Mais attention, certains navigateurs ont des politiques de nettoyage automatique des données locales, surtout si l'utilisateur n'a pas visité le site depuis un certain temps. Donc, si tu as besoin de conserver des données sur le très long terme, faut peut-être envisager d'autres solutions (stockage côté serveur, par exemple). Quelques exemples concrets : * **Cookies :** Idéal pour les petits jetons d'authentification (mais attention à la sécurité, hein !), les préférences utilisateur basiques (langue, thème), le suivi de session (mais il y a mieux maintenant). * **Local Storage :** Parfait pour stocker des données hors ligne (genre un brouillon d'article), des assets pour améliorer les performances (images, fichiers CSS), des données utilisateur plus volumineuses (profil utilisateur détaillé). Dans tous les cas, il faut bien penser à la confidentialité des données et au RGPD. Faut informer l'utilisateur de ce que tu stockes et pourquoi 🔐. J'espère que ça t'éclaire un peu ! N'hésite pas si tu as d'autres questions.
C'est intéressant comme approche. Mais quand tu dis "donnéesutilisateurplusvolumineuses", tu penses à quoi exactement comme volume ? Parce que 5-10MB, ça peut vite être dépassé si on parle de fichiers multimédia par exemple, non ? Du coup, est-ce qu'il y a des seuils à ne pas franchir pour le local storage, ou des alternatives à envisager si on a vraiment beaucoup de données ?
Alors, quand je parle de données volumineuses, je ne pensais effectivement pas à des fichiers multimédia en tant que tels. Disons que c'est plus pour du texte, des données de configuration complexes, ou des petits fichiers binaires encodés en base64 (mais là, faut faire gaffe à la performance). Pour de la vidéo ou de l'audio, c'est clair que le local storage devient vite limité. Si tu dois gérer des gros volumes, tu peux regarder du côté d'IndexedDB, qui est une base de données NoSQL directement intégrée au navigateur. C'est plus complexe à mettre en oeuvre que le local storage, mais ça offre beaucoup plus de flexibilité et de capacité. Autre option, le stockage côté serveur, mais là, on change de paradigme, hein !
Je me permets d'ajouter une petite astuce concernant le local storage, surtout si vous manipulez des données sensibles (même si ce n'est pas l'idéal, comme dit plus haut). Vous pouvez utiliser une librairie de chiffrement JavaScript (comme CryptoJS) pour chiffrer les données avant de les stocker et les déchiffrer après les avoir récupérées. Ça ajoute une couche de sécurité supplémentaire, même si ça ne remplace pas les bonnes pratiques de base.
Pour compléter ce qui a été dit, pensez aussi à la "SessionStorage". C'est un peu le parent pauvre, mais c'est très pratique pour les données temporaires qui ne doivent pas survivre à la fermeture de l'onglet. Typiquement, des infos de formulaire en cours de remplissage, ou des préférences de navigation le temps d'une session. C'est effacé dès que l'utilisateur ferme la page, ce qui simplifie pas mal la gestion de la confidentialité. Parfait pour des sites e-commerce par exemple !
Exactement, VisionnaireNum, la SessionStorage est top pour tout ce qui est temporaire. Un truc auquel on ne pense pas toujours, c'est aussi pour les A/B tests. Stocker la variante qu'on a montré à l'utilisateur pendant sa session, ça évite de lui afficher une version différente à chaque page. Bêtement efficace !
L'idée des A/B tests avec la SessionStorage, c'est bien vu ! On peut aussi imaginer l'utiliser pour stocker temporairement les filtres de recherche appliqués par l'utilisateur sur un site e-commerce, ça améliore l'UX et ça ne pollue pas le LocalStorage avec des données inutiles sur le long terme.
Bien vu BlockSturm65 ! Et pour aller plus loin dans cette logique d'optimisation de l'UX, on peut aussi utiliser la SessionStorage pour mémoriser l'état d'un lecteur audio ou vidéo. Comme ça, si l'utilisateur recharge la page, il reprend la lecture exactement où il s'était arrêté pendant sa session. C'est un petit détail qui fait la différence.
C'est une excellente application ! Et pour aller encore plus loin, on pourrait imaginer l'utiliser pour enregistrer la position de l'utilisateur dans un long article ou tutoriel. Comme ça, s'il revient plus tard, il reprend directement là où il en était. Une sorte de marque-page numérique, quoi.
L'idée du marque-page numérique, c'est vraiment dans l'esprit d'une UX soignée 👍. Ça me fait penser qu'on pourrait combiner SessionStorage et LocalStorage pour une expérience encore plus fluide. Par exemple, on pourrait stocker la position de lecture *actuelle* dans la SessionStorage (pour la session en cours, comme tu disais), et *sauvegarder* cette position dans le LocalStorage uniquement si l'utilisateur ferme volontairement la page ou clique sur un bouton "enregistrerlaprogression". Comme ça, on évite de surcharger le LocalStorage avec des données temporaires et on offre une continuité même après plusieurs jours. En parlant de LocalStorage, je me demande si certains d'entre vous ont déjà rencontré des problèmes de *quota* ? J'ai lu que la taille variait pas mal selon les navigateurs (entre 5 et 10MB, comme disait CodeAlambic), mais est-ce que vous avez des retours d'expérience sur les limites *réelles* ? Genre, est-ce que ça arrive souvent de saturer le LocalStorage, et quelles sont les meilleures stratégies pour gérer ça ? 🤔 J'imagine qu'on peut mettre en place des mécanismes de rotation (supprimer les données les plus anciennes), mais ça demande une certaine gymnastique... Autre question : est-ce que vous avez déjà testé des librairies polyfill pour le LocalStorage ? Histoire d'assurer une compatibilité maximale, même avec des navigateurs un peu... *rétro* 😉. Parce que bon, un site qui fonctionne nickel sur Chrome mais qui plante sur IE8, c'est pas top pour l'image de marque 😅. Et pour finir, une petite pensée pour le RGPD : n'oubliez pas de bien informer vos utilisateurs de ce que vous stockez dans le LocalStorage (et pourquoi !). La transparence, c'est toujours une bonne politique 😉. Sinon, gare aux sanctions ! 💸
C'est pertinent de rappeler les quotas du LocalStorage, LexikaFlow17. Par contre, je suis pas certain que se prendre la tête avec des polyfills pour IE8 soit un investissement très judicieux en 2024. Le temps passé là-dessus serait mieux utilisé sur l'optimisation pour les navigateurs récents, non ?
Je suis d'accord avec toi, EchoShift69. Honnêtement, investir du temps sur des navigateurs aussi anciens qu'IE8 en 2024, c'est probablement une perte de ressources. À moins d'avoir une cible trèèèèès spécifique qui utilise encore ce navigateur (et avec des arguments béton pour justifier cet effort), ça me semble plus pertinent de concentrer ses efforts sur l'optimisation pour les navigateurs modernes et leurs dernières versions. D'autant plus que, d'après StatCounter, IE représentait moins de 0,05% du marché mondial des navigateurs en décembre 2023. Même en considérant une marge d'erreur, on est sur des chiffres tellement faibles que le retour sur investissement serait quasi nul. Après, pour revenir sur la question des quotas du LocalStorage, c'est vrai que c'est un point à surveiller, surtout si on stocke des données potentiellement volumineuses. J'ai trouvé une étude de Mozilla qui indique que la majorité des navigateurs modernes (Chrome, Firefox, Safari) allouent entre 5 et 10 Mo par origine (domaine + protocole). Mais il y a des exceptions, notamment certains navigateurs mobiles ou des versions plus anciennes qui peuvent avoir des limites plus basses. Du coup, comme le suggérait LexikaFlow17, mettre en place une stratégie de rotation des données (supprimer les données les moins récentes ou les moins utilisées) me paraît une bonne pratique. On pourrait par exemple implémenter un système de cache avec une durée de vie limitée pour les données stockées dans le LocalStorage. Et bien sûr, toujours informer l'utilisateur de ce qu'on stocke et pourquoi, conformément au RGPD. Et pour ceux qui veulent creuser le sujet des quotas, je recommande de consulter la documentation de Mozilla Developer Network (MDN). Ils ont un tableau comparatif des limites du LocalStorage par navigateur qui est régulièrement mis à jour. C'est une ressource précieuse pour éviter les mauvaises surprises.
Ok, si je récapitule rapidement ce qui a été dit : on a exploré les différences entre cookies, local storage et session storage, leurs avantages et inconvénients respectifs en termes de sécurité, de taille et de durée de conservation 🤓. On a aussi parlé d'IndexedDB pour les gros volumes et de l'importance du RGPD. On a vu des exemples concrets d'utilisation (authentification, données hors ligne, A/B tests, etc.), et on a même évoqué la question des quotas du LocalStorage et des stratégies de rotation des données. 👏 On est d'accord qu'il faut oublier IE8 😂. C'est un bon résumé, non ?
Quand tu dis qu'il faut oublier IE8, BadmintonMaster, tu veux dire qu'on ne devrait même pas envisager un affichage dégradé basique, ou juste qu'on ne se prend pas la tête avec des polyfills complexes pour que le site fonctionne *exactement* comme sur Chrome ? Parce que parfois, un simple message "Votrenavigateurestobsolète,veuillezmettreàjour" peut suffire, non ? Ou est-ce qu'il y a des cas où même ça, c'est overkill ?
Non, non, quand je dis "oublierIE8", je veux dire qu'on ne se prend pas la tête à *rien* faire de spécifique pour lui. Même pas un message d'alerte. Si quelqu'un utilise encore IE8 en 2024, il est probablement habitué à ce que les sites soient cassés, et c'est son problème, pas le nôtre ! 😂 Plus sérieusement, je pense que c'est du temps et de l'énergie perdus pour un bénéfice quasi nul. Autant se concentrer sur les navigateurs modernes et les bonnes pratiques d'accessibilité, qui bénéficieront à tous les utilisateurs, y compris ceux qui utilisent des navigateurs un peu anciens (mais pas IE8, soyons clairs !). Après, si on a une cible très spécifique qui utilise encore IE8 (genre, une administration publique qui n'a pas mis à jour son parc informatique depuis 15 ans), on peut envisager un affichage dégradé basique, mais c'est vraiment un cas extrême. Et dans ce cas, je pense qu'il vaut mieux faire appel à un expert qui saura gérer les spécificités d'IE8 sans compromettre la qualité du site pour les autres navigateurs.
Perso, je suis d'accord, IE8, on oublie. Mais il y a un truc auquel il faut faire gaffe quand on dit ça, c'est l'accessibilité. Souvent, les techniques qu'on utilise pour que nos sites soient accessibles aux personnes handicapées, ça bénéficie aussi aux vieux navigateurs. Genre, si on fait un site bien structuré avec du HTML sémantique, il y a des chances que ça s'affiche correctement même sur un navigateur un peu dépassé. Sans qu'on ait besoin de se prendre la tête avec des polyfills ou des messages d'alerte relous.
BadmintonMaster : le 23 Février 2025