Vous le savez, les cookies font grossir. Pour éviter de grossir on peut bannir les cookies. On peut tenter d’en manger un seul de temps en temps, quitte à ce qu’il soit un peu gros, plutôt que grignoter toute la journée. Il est aussi bon de se mettre des directives simples comme laisser les cookies à la cuisine et ne jamais les amener dans le salon.
Vous savez ? dans le web c’est la même chose, exactement.
La problématique du cookie
Sur le web un cookie c’est une donnée stockée par votre navigateur et envoyée avec chaque requête vers le serveur web. La donnée est généralement petite, entre 50 et 2000 octets, mais elle est envoyée avec toutes les requêtes.
L’équipe performance de Yahoo! a fait des tests qui révèlent qu’un cookie de 1ko retarde la réponse d’environ 16ms sur une connexion ADSL. Ce n’est rien, c’est négligeable. Mais comptez, il est fréquent d’avoir une cinquantaine de composants externe sur une page riche. Orange dont j’avais parlé lundi monte même à 80 composants. Avec une simple multiplication on obtient 1,3 secondes pour un cookie de 1ko. Là ce n’est plus négligeable du tout. Notre cookie vient de nous faire rater plus d’une seconde alors que 100ms de retard signifient déjà 1% de vente en moins.
Les préconisations
Votre cookie peut être plus petit, la plupart le sont, mais l’arithmétique fait que presque rien multiplié par beaucoup trop ça reste encore pas mal.
J’ai quatre préconisations à vous apporter :
- N’utilisez pas le cookie pour stocker le contenu de vos sessions. Ce contenu doit être sur le serveur, le cookie ne servant qu’à stocker un jeton unique identifiant l’utilisateur.
- Gardez une taille minimum pour vos cookies. Plus ils sont petits moins ils impacteront les performances et parfois un petit gain répété.
- Limitez vos cookies au sous domaine ou au chemin nécessaire, afin de faire en sorte qu’ils ne soient pas utilisés partout inutilement.
- Utilisez un domaine ou un sous domaine spécifique pour vos composants statiques (images, javascript, feuille de style) et n’y insérez aucun cookie. Ainsi vous évitez de multiplier la pénalité du cookie par le nombre élevé de composants dans votre page.
Salut,
ce n’est pas directement dans le sujet mais as-tu entendu parlé de http://www.thomasfrank.se/sessionvars.html qui ne concerne du coup que les valeurs non persistantes mais qui par conséquent permet de s’affranchir des cookies ? La méthode repose sur l’utilisation de « window.name ».
Je me doute que cette méthode relève plus du dépannage que de la bonne pratique comme tu le préconises mais dans un monde imparfait, ça dépanne.
Hum… Cela ne fait-il pas quatre préconisations ? 😉
@GôTô: si mais la seconde compte double 😉 plus sérieusement c’est corrigé, merci.
@Adrien: oui, mais j’ai toujours une répulsion naturelle à détourner un outil de son usage et à exploiter des effets de bord. D’expérience c’est toujours quelque chose qui te revient sur le coin de la g*.
Mais là en plus ça pose plein de problèmes :
– Ca ne sert que ce qui est pur frontend vu que contrairement aux cookies le serveur ne « voit » jamais ce qu’on y stocke. Pas de préférence importance donc.
– On ne peut rien y stocker qui est même un minimum sensible vu qu’il n’y a pas d’isolation des domaines
– Ca pose de sérieux problème de vie privée (non seulement un site tiers peut connaitre tes préférences, mais aussi vérifier si tu as visité tel ou tel site tiers)
J’ai du mal à voir dans quel cas elle est plus intéressante qu’un cookie en fait.
Ouais, les cookies faut qu’ils soient petits.
Si on a juste besoin d’accéder aux données côté client, on peut regarder du côté de localStorage, sessionStorage, database storage. Pas de transmission sur le réseau et plus propre que le hack window.name. Mais pas encore supporté par tous les navigateurs.