Impact du cache HTTP

Le cache HTTP permet aux visiteurs de ne pas re-télécharger les pages ou les éléments de pages qui l’ont déjà été. C’est un des meilleurs mécanismes pour accélérer l’accès du navigateur au contenu mais il est mis en échec par de nombreux cas.

• Camille vient sur votre site pour la première fois. Il n’a jamais téléchargé aucun de vos contenus, le cache HTTP ne lui sera d’aucune utilité pour ce premier accès.
• César est ce qu’on appelle un power user malgré l’opposition entre le terme et la connotation qu’on lui prête. Il a touché la configuration de son navigateur, par exemple en demandant à Microsoft Internet Explorer de vérifier les mises à jour des pages « à chaque fois », et depuis son navigateur ignore toutes les directives de cache.
• Carole a installé sur son micro-ordinateur un logiciel extra-ordinaire qui protège sa vie privée, nettoie les fichiers inutiles et assure sa sécurité. Ce logiciel efface le cache du navigateur régulièrement. Carole est déjà venue sur le site, mais son logiciel a effacé toute trace des éléments qui auraient pu être mis en cache.
• Céline, enfin, a une configuration tout à fait classique. Elle navigue parfois sur notre site, mais entre ses visites elle va voir aussi d’autres pages. Son cache est renouvelé pour y mettre les éléments de sites tiers, et les éléments qu’elle avait mis en cache pour notre site ont été effacés pour faire de la place.

Ces quatre personnes ne sont pas isolées, leur situation est même assez fréquente. Malgré toute votre volonté pour que vos visiteurs reviennent chaque jour, le cas de Céline est assez fréquent.

Au final, si on devait donner un chiffre, pour un site bien configuré, on pourrait dire que 50% des visites se font avec un cache rempli (c’est à dire que les éléments de votre page seront utilisés à partir du cache et non re-téléchargés). Le nombre de pages vues avec un cache efficace est cependant bien plus grand : Une fois la première page chargée, les suivante réutiliseront certainement les mêmes composants graphiques, à partir du cache. Le nombre d’accès « avec cache rempli » peut donc représenter 75 à 80% des pages vues.

Ce serait agréable si vous pouviez vous fier à mes chiffres, mais vous ne le pouvez pas. Cela dépend de votre site. Quel est le nombre de pages vues par visite ? Quelle est la proportion de nouveaux visiteurs sur votre nombre de visites quotidiennes ? Vos habitués viennent-ils tous les jours ou toutes les quinzaines ? Votre site est-il un portail qui pointe vers des sites tiers, un site de contenu éditorial dans lequel on fouille ou un site « réponse » sur le quel on trouve ce qu’on cherche et qu’on quitte ensuite ?

Chaque cas est différent. Connaître les chiffres adaptés à votre situation spécifique est important. Ce sont ces chiffres qui vont vous permettre de cibler votre première priorité : optimiser le premier accès sans cache (donc en mettre le moins possible, quitte à mettre plein de petits fichiers différents sur chaque page), ou optimiser les accès avec cache (donc préférer en charger autant que possible d’un coup, quitte à ce que tout ne soit pas utilisé immédiatement sur la page courante) .

Le protocole de test

Maintenant que nous avons défini le problème, il faut répondre à notre question. Quels sont les utilisateurs qui viennent potentiellement avec un cache rempli ?

Le test est semble assez simple, il suffit d’inclure deux éléments dans vos pages : un élément mis en cache, et un élément non mis en cache. En faisant comptant le nombre d’accès à ces éléments on pourra obtenir le pourcentage de pages avec un accès « cache rempli ».

La première subtilité est de retirer les moteurs de recherche et les robots divers. Tous ne suivent pas les recommandations du robots.txt et les outils de statistiques sont reconnus très mauvais pour différencier les robots des vrais utilisateurs. Une solution peut être de faire charger vos deux éléments tests par javascript. Les robots n’exécutent pour ainsi dire jamais javascript et cela les exclue de fait de nos mesures. Nous excluons du même coup quelques utilisateurs réels qui n’exécuteront pas javascript mais il est probable que cela ne changera pas fondamentalement nos résultats qui sont fondés sur des proportions et pas des valeurs absolues.

La seconde subtilité est de ne pas dégrader excessivement la page uniquement pour faire une mesure statistique. Nos éléments de test doivent donc absolument être chargés après le contenu normal de la page, et même après l’exécution potentielle des scripts qui eux aussi s’exécutent habituellement après le contenu de la page. Une solution est d’écrire votre javascript à la toute fin de la page, juste avant de fermer la balise </body>, et d’enregistrer une fonction sur l’événement « load » de la fenêtre. Cette fonction insèrera les appels vers nos deux éléments de test. Exceptionnellement, et vu qu’il ne s’agira que d’une ou deux lignes, je vous conseille aussi d’inclure le script directement dans la page HTML et pas dans un fichier externe.

Voici le code que je vous propose :

<script type="text/javascript">
var test_cache = function() {
var avec = new Image(1,1) ;
avec.src = "adresse de votre image avec entêtes de cache" ;
var sans = new Image(1,1) ;
sans.src = "adresse de votre image sans entêtes de cache" ;
}
if (window.addEventListener) {
window.addEventListener("load",test_cache,false);
} else if (window.attachEvent) {
window.attachEvent("load",test_cache);
}
</script>

Assurez vous que votre première image contient bien toutes les entêtes HTTP qu’il faut pour qu’elle soit mise en cache, par exemple une entête « Expires » avec une date suffisamment dans le futur. Assurez vous de même que la seconde image ne sera jamais mise en cache. Là c’est parfois plus compliqué mais les entêtes Pragma, Cache-Control, et une date dans le passé pour l’entête Last-Modified devrait achever toute ambiguité pour votre navigateur.

Enfin, chaque image devra être la plus petite possible. Dans l’idéal il faudrait que la requête et la réponse du serveur HTTP soit inférieure à 1ko. Cela implique par exemple de poser vos images sur un domaine où l’utilisateur n’aura pas de cookie, ou des cookies de faibles tailles.

Lire les chiffres

La première donnée est assez simple à lire dans les journaux d’accès de votre serveur web. Laissez passer deux bonnes semaines pour que vos visiteurs construisent leur cache, puis comptez le nombre d’accès à votre première image, comptez le nombre d’accès à votre seconde image, le rapport entre les deux vous donnera le pourcentage de pages qui sont lues « avec un cache rempli ».

Ce n’est cependant pas forcément la partir la plus intéressante. Si beaucoup de pages sont lues avec cache mais que la première page de chaque visite est toujours sans cache et outrageusement lente, vous perdez des visiteurs. En regardant les IP ou en utilisant des cookies avec identifiants uniques, tentez de vérifier quel pourcentage d’utilisateur a téléchargé la première image (avec cache). Avec ce chiffre vous aurez le pourcentage de visiteur « avec cache remplie lors de leur premier accès ».

Maintenant c’est à vous

Maintenant c’est à vous. Quelle est votre méthodologie pour analyser les accès avec cache et sans cache ? Voyez vous un moyen d’améliorer ma procédure ?

Ensuite je vous encourage à mettre en oeuvre cette procédure, et venir poster vos résultats ici.