Mots-clé : cookie

YSlow : Utiliser des domaines sans Cookie : traduction

Je viens de traduire un gros morceau du texte ici.

Lorsque le navigateur fait une requête pour une image statique, il envoie tout de même les cookies dans la requête. Le serveur ne se sert absolument pas de ces cookies. Ils créent donc un traffic supplémentaire totalement inutile. Il faut s’assurer que tous les composants statiques tels que les images sont récupérés sur des domaines sans cookie. Par exemple, il suffit de créer un sous-domaine static, et d’y mettre les composants adéquats.
Par exemple, si le domaine est www.example.org, il suffit de mettre les composants statiques sur static.example.org. Néanmoins, si vous avez déjà mis en place des requêtes sur le domaine de plus haut niveau, soit example.org, alors les cookies suivront tout de même sur static.example.org. Une solution est d’acheter un nom de domaine dédié.
Par exemple, Yahoo! utilise yimg.com, Youtube utilise ytimg.com et Amazon utilise images-amazon.com.
Un autre bénéfice concerne les proxies : certains proxies refusent de mettre en cache des composants qui ont été demandés avec des cookies. Pour la note, si vous vous demandez s’il vaut mieux utiliser example.org ou www.example.org pour votre page de base, pensez à l’impact des cookies. Le fait de supprimer www ne vous laissera pas d’autre choix que d’écrire des cookies qui seront tous diffusés sur *.example.org.
Donc, pour des raisons de performance, c’est mieux d’utiliser le sous domaine « www » et d’écrire les cookies pour ce sous-domaine.


Vous ne voyez pas que je suis en train de pleurer ? J’ai tout faux sur la plupart des sites Internet que j’ai crée. Bon, aujourd’hui c’est nettement moins problématique que si nous étions dix ans en arrière, mais c’est très agaçant de savoir que tout le travail mis en place est à revoir (règles de réécriture, traducteur, etc)… et le discours que je tenais qui va avec (pas la peine des www). On en apprend tous les jours !