Comprendre et analyser les performances d’un site internet
PARTIE 1 – Comprendre
Introduction
L’internaute n’aime pas attendre quand il fait ses achats en ligne. Il veut pouvoir faire ce qu’il a à faire le plus vite possible. Si le site répond lentement, l’utilisateur se posera des questions : “ Est-ce que le site a compris que j’ai cliqué ?”, “Est-ce que j’ai un souci avec Internet ? ”, etc. Imaginez que vous posiez une question à quelqu’un et que cette personne ne vous répond pas. Vous allez sûrement vous demander si cette dernière vous a bien entendu, voire même écouté. Vous allez peut-être trouver désagréable le fait que votre interlocuteur prenne tout son temps pour vous répondre, c’est pareil pour un site internet.
Un site qui charge rapidement est un site avec lequel il sera plus agréable de communiquer. Un point à ne pas négliger pour les e-commerçants, par exemple, qui se doivent de fidéliser leurs clients. Il suffit que l’internaute ne soit pas assez patient pour attendre quelques secondes et il ira voir à la concurrence. Cela signifie de l’argent de perdu pour l’entreprise. Imaginez alors les entreprises comme Cdiscount, deuxième e-commerçant en France à l’heure actuelle, qui doit supporter plus d’une douzaine de commandes à chaque seconde ! Vous l’aurez compris, selon l’activité de l’entreprise, la performance web n’est pas quelque chose à négliger. Stop ! Je vous arrête un instant. Je ne suis pas en train de dire que si vous avez un site, vous avez BESOIN de lire cet article ou que votre site aura les mêmes performances que celui de Cdiscount. Dites-vous bien que ce
genre d’entité dispose d’une infrastructure énorme.
Je vous propose plutôt d’avoir quelques connaissances et des outils pour analyser vous-même les performances de votre site mais surtout, comprendre ce qui est important de tester quand on parle de “ test de performance ”. En effet, on voit beaucoup d’outils sur Internet qui proposent d’analyser gratuitement ou non une page web, mais chacun peuvent fournir des résultats très différents. Qu’est-ce qui est testé derrière ? Est-ce vraiment fiable ? Dans cet article, je ne vous donnerai pas de simples conseils génériques à suivre (compression des ressources, réduire les redirections, etc.).
Je vous proposerai plutôt des méthodes concrètes d’analyse et de faire un peu dans la technique !
Tout d’abord, nous allons voir ensemble qu’améliorer les performances d’un site c’est aussi connaître différentes métriques, une toute particulièrement, et savoir les examiner pour comprendre ce qu’il faut améliorer en priorité. Ensuite, je présenterai différents types d’outils de monitoring avec des exemples d’utilisation. Je précise aussi que cet article se veut accessible à tous avec le minimum d’outils nécessaires pour pratiquer de son côté. Ainsi, les outils complexes à maîtriser (et payants) tels que Dynatrace ne seront pas détaillés ici.
Les enjeux de la performance web et ses métriques
Qu’est-ce que la performance web
D’après ce site ( http://glossaire.infowebmaster.fr/wpo/ ), l’Optimisation de la Performance Web (ou “Web Performance Optimization”) désigne “ une discipline qui se charge d’améliorer la vitesse de téléchargement et d’affichage des pages web ”.
SES ENJEUX
Si la définition est assez évidente pour certains, les enjeux des performances d’un site le sont beaucoup moins et peuvent avoir des conséquences lourdes pour une société. Vous ne me croyez pas ?
Voici un article ( https://www.gigaspaces.com/blog/amazon-found-every-100ms-of-latency-cost-them-1-in-sales/ ) qui relate une mésaventure vécue par Amazon en 2009 expliquant que 100ms de latence supplémentaire a réduit le chiffre d’affaire du géant d’internet de 1% !
Voici un deuxième exemple ( https://blog.mozilla.org/metrics/2010/04/05/firefox-page-load-speed-part-ii/ ) qui
raconte que le gain de 2,2s sur la landing page de Mozilla en 2008 a amélioré le taux de conversion des téléchargements de 15,4%, soit un gain de 60 millions de téléchargements supplémentaires par an !
Vous l’aurez compris, selon l’activité/le contexte d’une société, la performance web peut être une notion à ne pas prendre à la légère afin de satisfaire l’impatience des utilisateurs.
Comment mesurer la performance ?
Pour mesurer les performances, on aurait pu s’attarder uniquement au temps de chargement des pages d’un site. Mais ce serait très incomplet comme analyse.
Attends, tu as bien dit dans ta définition, plus haut, qu’il s’agit « d’améliorer la vitesse de téléchargement et d’affichage des pages web ». Tu ne te contredis pas un peu là ?
Je précise que là je parle de MESURER la performance. En soi, notre but final est bien d’améliorer le temps de chargement mais si vous chargez plusieurs fois à la suite une page web, vous risquez de ne pas avoir tout à fait les mêmes temps de chargement. Alors comment déduire notre scoring de performance ? Grâce à des métriques !
Analyser une page web
Le rôle de quelques métriques dans une page web.
Le chargement d’une page web se fait en plusieurs étapes. Avec l’image plus bas, je vais vous expliquer quelques métriques :
“Seulement « quelques métriques » ? Pourquoi ? Tu ne les connais pas toutes ?”
Toutes les métriques qui existent ? Et bien, non ! Désolé de vous décevoir mais il y en a beaucoup trop à connaître (beaucoup plus que sur le schéma) et seulement quelques unes vont nous intéresser pour les besoins de l’article. Mais rassurez-vous, si vous tenez à connaître toutes celles du schéma, je vous ai laissé son URL dans les sources 😉
Request : Délai qui débute à l’émission de la demande des informations d’une page (provenant de l’ordinateur utilisateur qui est adressée au serveur) pour accéder à la page et qui se termine par la réception du début de la réponse.
Response : Temps de réponse que met le serveur à donner toutes les informations liées à la page que l’internaute veut regarder.
DOM Interactive : Moment où le code HTML a fini d’être analysé et où la construction du DOM est terminée.
DOM Content Loaded : Moment où le DOM est prêt et où aucune feuille de style n’empêche l’exécution du JavaScript. Il est alors possible de construire la structure de la page.
DOM Complete (ou “ Load Time ”) : Moment où la totalité du traitement est terminée et le téléchargement de toutes les ressources sur la page (images, etc.) est terminé. Cet événement est déclenché en même temps que le “window.onload()”. Il a longtemps été la valeur de référence de la performance web mais il ne l’est plus. En effet, il ne permet pas de déterminer le moment où une page web devient utile. Un utilisateur peut commencer à interagir avec la page avant cet événement.
En plus des métriques du schéma, voici deux autres qui sont utiles à connaître :
Start Render : Moment où la page blanche laisse place aux premiers éléments de la page web.
Fully loaded : Moment où la totalité des ressources d’une page web (dont les ressources externes non visibles) a été chargée.
Voici déjà quelques métriques utiles à connaître pour comprendre les résultats d’un outil que nous verrons plus bas. Ce sont des métriques “classiques” mais ce ne sont pas des métriques de référence, plus maintenant en tout cas.
Remarque : En regardant bien ce schéma, on distingue trois parties qui sont la connexion, le temps serveur et le temps client.
Analyser une waterfall
Prenons un exemple concret pour donner un sens à tout ce blabla. Parlons de waterfall ! Le waterfall est une représentation du chargement des éléments de votre page web par le navigateur au cours du temps.
Lorsqu’un internaute navigue sur une page internet précise, avec Google Chrome par exemple, ce dernier peut à tout moment utiliser ChromeDevTools en appuyant sur la touche “F12” du clavier. Si vous le faites sur une page quelconque, que vous cliquez sur l’onglet “Network” et rechargez la page, vous aurez quelque chose comme ça :
Vous l’avez compris, on voit le temps de chargement de toute une batterie de ressources. Mais on voit aussi bien d’autres choses ! Je n’en dis pas plus pour le moment mais sachez que nous allons revoir cette notion de waterfall avec un outil plus adapté pour des analyses 😉
On voit mieux comment est chargée une page web et comment chaque partie du chargement peut être mesurée mais un problème fondamental subsiste… On ne se rend pas bien compte de la qualité de l’expérience utilisateur, comment la mesurer ? En utilisant une autre métrique : le Speed Index.
Speed Index : une métrique de référence
Une métrique de référence qui mesure le mieux l’expérience client sur un site (pour le moment) : le Speed Index. Ce n’est pas la seule métrique qui soit très importante mais pour éviter de trop rallonger cet article, je m’efforcerai de parler surtout du Speed Index.
Il s’agit d’une métrique qui mesure la performance des sites web en calculant le taux de remplissage de la page, c’est-à-dire le pourcentage de remplissage de la page web jusqu’à la ligne de flottaison en un temps donné (en millisecondes). Son unité de mesure est de %/ms. Cette métrique est plus ou moins visible dans le waterfall vu plus haut, ainsi que d’autres métriques. Cependant, le waterfall se remplit très rapidement et on n’a pas le temps de regarder en détails ce qu’il se passe.
Voici un exemple pour mieux comprendre le fonctionnement du Speed Index : on illustre ici la progression visuelle du chargement des pages A et B en exemple ci-dessus.
On constate que les pages A et B ont des temps de chargement total identiques d’environ 12 secondes et des Start Render (moment où la page blanche laisse place aux premiers éléments de la page web) identiques d’environ 300ms. Cependant, on peut voir que plus de 90% de la page A est chargée en environ 1 seconde. Au contraire, seul 20% de la page B est affichée lors de la 1ère seconde et il faut attendre près de 10 secondes pour obtenir un rendu visuel proche de la page A.
Plus le chiffre est bas, plus la page s’affiche rapidement. Le Speed Index est la mesure la plus fiable car elle est basée sur la progression visuelle du chargement de la page et met en lumière le rythme auquel les éléments au-dessus de la ligne de flottaison s’affichent. Cette métrique est celle qui exprime donc le mieux l’expérience utilisateur. Mais comment mesurer cette métrique si elle est si importante mais difficilement visible depuis la ChromeDevTools ?
Dans la suite de l’article, nous verrons ensemble les outils de monitoring et de tests !
CET ARTICLE A ÉTÉ RÉDIGÉ PAR :
