Il ne s’agit pas de revenir sur l’outil, mais de vous signaler une vidéo (en anglais) qui détaille pendant 25 minutes comment utiliser l’outil et ce qu’il propose. Si vous souhaitiez une introduction, la voici. On y parle non seulement de l’outil, mais des connexions TCP, des CDN, etc.

La seconde nouveauté c’est l’arrivé dans l’outil en ligne de nouvelles statistiques pour votre analyse. Tout d’abord une troisième vue, qui vous donne la répartition des téléchargement par type. Êtes-vous bloqués par vos CSS ? vos images ?

Ensuite, et c’est peut être le plus important, c’est une vue graphique du remplissage des différentes files de téléchargements. On y voit très clairement la limitation de nombre de connexions simultanées, quand un contenu bloque toutes les files, ou quand un serveur refuse les connexions persistantes. C’est finalement bien plus utile par certains points que le graphique en cascade. Vous trouverez ça juste en dessous du graphique en cascade.

Le concept de ces outils est le même : on prend une URL, on lance la page, et on trace la cascade des requêtes HTTP avec quelques statistiques. C’est là qu’on voit le temps pris par chaque composant, par la somme des composants, et les éventuels problèmes de performance comme les scripts bloquants.

Pingdom : simple et clair

Le plus simple, et peut être le plus joli, c’est Pingdom. Il se contente de tracer la cascade, en précisant les temps de connexion TCP, d’envoi et de réception, ainsi que les poids des divers composants. Il n’y a pas de paramétrage, et il semble que le moteur se permette de lancer presque 10 connexions simultanées. Bref, n’en faites pas des analyses trop poussées. Par contre pour montrer l’aperçu de la cascade ou un problème significatif au détour d’une conversation, c’est clairement un des outils à retenir. L’interface est en effet suffisamment jolie pour attirer le non-spécialiste.

Site-perf : paramétrable jusqu’au bout

Le deuxième outil en ligne est site-perf. Le site se veut regrouper des informations sur la performance des sites web, mais c’est surtout pour son test de performance en ligne qu’il est intéressant. Il offre plusieurs sources géographiques pour lancer le test et un paramétrage complet : nombre de connexions simultanées, bande passante, latence, qualité de la ligne (% de perte de paquets), compression, keep-alive, login, adresse IP… tout y est. Je n’ai pas fait suffisamment de test pour m’assurer que le résultat est précis ou cohérent avec les outils « de confiance » comme IBM Page Detailer, mais le résultat est sans appel : une cascade précise avec six états, dont le temps de résolution DNS, le détail des informations de cache HTTP, et un résumé cohérent.

Les deux seuls défauts sont la largeur de la cascade, qui mériterait de pouvoir prendre plus de place pour une meilleure lecture, et le manque d’un résumé par type de composant (combien m’ont coûté les images au total ?).

Web Page Test : aussi complet que la version bureau

Le dernier outil c’est webpagetest, la version en ligne de AOL Page Test. La cascade est précise et on peut avoir confiance dans l’outil si c’est juste une automatisation de la version bureau du logiciel. Moins joli que pingdom (en fait même carrément moche), webpagetest est aussi légèrement moins paramétrable que site-perf.

On a accès à trois sources géographiques avec leurs spécificités, et un choix du nombre de requêtes simultanées. Pour rattraper le tout il est possible de scripter le test. On peut aller réaliser un parcours sur le site, envoyer un formulaire ou accéder une page protégée par authentification. Il manque malheureusement la possibilité de modifier finement la bande passante ou de modifier la latence artificiellement. Vu l’importance de la latence dans les tests, c’est dommage.

L’intérêt de webpagetest c’est surtout le résultat. On y retrouve une cascade précise et très claire (en grande largeur), qui comprend aussi les temps de début de rendu et de fin de rendu de la page : indispensable si on veut jouer sur le ressenti utilisateur et pas uniquement sur les chiffres bruts.  Derrière cette cascade on a un résumé ressource par ressource des différents temps et poids, avec toutes les entêtes HTTP. Bref, tout ce qui est nécessaire pour travailler. Il y a même un tableau avec des recommandations pour vérifier des critères comme le cache, gzip, la concaténation css/js, le keep-alive, la minimisation ou le keep-alive.

Le double effet kisskool de webpagetest c’est que ces informations sont fournies en double : une fois pour le premier accès avec un cache vide, et une seconde fois, pour simuler un cache correctement initialisé. Indispensable là aussi. Mieux, cascade et résumés sont disponibles sous forme d’image et peuvent donc facilement être sauvegardés pour un rapport ou pour comparaison entre deux dates.

Pour les utilisateurs bas débit c’est une horreur. Le point positif c’est que pendant ce temps nos débits ont explosé et la latence des connexions a diminué. Bref, au final le temps moyen de chargement des pages des utilisateurs haut débit a légèrement baissé, mais c’est au prix d’un enfer pour tous les autres (le chiffre US est de 40% de RTC, en France il est plus faible mais non négligeable). A t’on bien fait ? pas certain.

Qu’y a t’on gagné ?

Si on y a gagné ces dernières années quand on surf ce n’est pas en performances mais en richesse et en qualité. Ou pas d’ailleurs. C’est ce que sous entend l’étude mais je ne peux m’empêcher de faire le parallèle avec nos micro-ordinateurs et nos logiciels. La puissance a vraiment explosé mais ce n’a pas tellement été pour faire les tâches plus rapidement. On s’est retrouvés avec de véritables monstres logiciels qui ont mangé chaque année la puissance gagnée. C’est au point où il est presque plus agréable de faire du traitement de texte sur un vieil ordinateur que sur la toute dernière bête de course associée aux derniers logiciels.

J’exagère mais l’esprit est là et je me demande si sur le web ce n’est pas la même chose. Peut être qu’on n’y a pas vraiment gagné en qualité mais que les développeurs font simplement moins attention. La seule exception que je vois c’est pour les vidéos, où là il y a vraiment eu un gain sensible pour le visiteur.

Des chiffres…

L’étude me donne ne fait à moitié raison, sans le dire. En 2006 les statistiques font état d’une page moyenne de 280 balises HTML pour 1440 pixels de haut. C’est beaucoup tout ça pour … 500 mots en moyenne. Ca fait deux mots par balise. Le rapport signal/bruit est agaçant. Pour des lignes de 15 mots on a environ un tiers de la hauteur seulement occupée par le contenu texte, c’est peu. Je ne vous propose pas de vous rassurer parce que entre 2006 et 2007, si le nombre de pages en tableau a été divisée par deux, le nombre de balise a suivi le chemin inverse : on passe à presque 600 balises par page en moyenne. Personnellement je n’ai pas eu l’impression que ça s’est traduit par plus de contenu dans les pages donc on doit être à plus d’une balise par mot en moyenne. De quoi donner des vertiges.

Mais ce n’est pas tout parce que sur nos 300Ko de page web on compte en moyenne 50ko sur 7 javascript (compressé), 10ko sur deux fichiers de style, plus les images, qui représentent 75% des requêtes (donc pour ceux qui suivent, à peu près 30 images par page).

Une saturation

J’hésite à continuer. Nous sommes des vrais malades.

Et si nous nous arrétions là ? je ne parle pas des chiffres de l’étude mais des délires des concepteurs web. Il est temps que nos machines ultrapuissantes connectés avec 1500 fois le débit que j’avais en 97, commencent à être plus rapides qu’à l’époque non ? Commençons à faire de la qualité et du contenu ou lieu de nous vautrer dans toute cette puissance pour faire quelque chose d’à peine mieux.

Un espoir

On peut toujours voir les choses sous plusieurs angles, alors voilà le bon : si réellement on a encore en moyenne deux feuilles de style, sept fichiers javascript et tant d’images, alors il y a une très bonne marge de progression côté performance pour un investissement très minime : concaténation des fichiers css, des fichiers javascript, et sprites pour les images.

Simple à mettre en oeuvre… en attendant de mettre fin au reste des délires.

• 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.