Site lent : que contrôler au-delà du score PageSpeed

Un score n'est pas un diagnostic. Un site peut avoir un score médiocre et être parfaitement utilisable, et peut en avoir un élevé tout en restant lent précisément au moment qui compte : quand quelqu'un ouvre la fiche d'un produit depuis son téléphone, hors de chez lui, avec un réseau incertain. Pour savoir si la lenteur freine vraiment les visiteurs, il faut regarder les pages qu'ils utilisent, sur les appareils qu'ils utilisent.

La question utile n'est pas « quel score obtenons-nous », mais « où et quand les personnes attendent, et qu'attendent-elles ».

Deux mesures différentes : le test simulé et l'expérience réelle

Les outils font deux choses souvent confondues, et cette confusion conduit à travailler sur le mauvais problème.

Les deux mesures s'utilisent ensemble, dans cet ordre : l'expérience réelle dit s'il vaut la peine de s'en occuper, le test simulé dit par où commencer. Ne regarder que le second conduit à courir après un score ; ne regarder que la première laisse sans savoir quoi toucher.

Ce qui pèse : images, vidéos, scripts et composants externes

Dans la plupart des sites d'entreprise, la lenteur ne vient pas d'un code mal écrit, mais de choses ajoutées une à une et jamais retirées.

• Images chargées à la taille de l'original et réduites par le navigateur : le visiteur télécharge une photo de qualité impression pour la voir grande comme un timbre-poste.
• Vidéos intégrées qui commencent à se télécharger dès l'ouverture de la page, même si personne ne les lancera jamais.
• Composants tiers : chat, bandeau de consentement, statistiques, cartes, encarts d'avis. Chacun semble léger, et ensemble ils déterminent quand la page devient utilisable.
• Polices de caractères : si le texte attend la police pour apparaître, on regarde une page vide alors que le contenu est déjà arrivé.
• Fonctions installées pour un besoin passé et jamais retirées, qui continuent de se charger sur toutes les pages.

Un exercice à la portée de tous : ouvrir une page et dresser la liste de tout ce qui n'est pas votre contenu. Pour chaque élément, se demander qui l'a voulu et ce qui se passe si on le retire. Souvent, la réponse est : personne ne s'en aperçoit.

Trois moments à observer, pas un seul

« Lent » décrit des expériences différentes, qui se corrigent de manières différentes.

1. L'ouverture : combien de temps s'écoule avant que le contenu principal n'apparaisse, celui pour lequel on est venu. Pas le premier pixel, pas le menu : le contenu.
2. La réponse : quand on touche un bouton ou qu'on ouvre un menu, combien de temps passe avant qu'il se passe quelque chose. Une page qui apparaît tout de suite mais ne réagit pas semble cassée, pas lente.
3. La stabilité : à quel point le contenu se déplace pendant qu'il finit de charger. C'est ce que les personnes décrivent comme « le site fait des bonds » : on va toucher un élément et sous le doigt en arrive un autre.

Le troisième est le plus négligé et souvent le plus gênant, car il ne fait pas perdre de temps : il fait commettre des erreurs.

Un registre des performances sur trois pages

La mesure n'est utile que si elle est reproductible. On choisit trois pages représentant des usages différents, on déclare les conditions et on enregistre avant et après chaque intervention, avec la date. Changer les conditions entre les deux relevés rend la comparaison inutile.

À côté de chaque ligne, on note la valeur mesurée et la date. Les chiffres ne se comparent pas à ceux d'autres sites, mais aux vôtres de la fois précédente : c'est la seule comparaison qui dit si l'intervention a servi.

Les priorités : d'abord retirer, ensuite différer, enfin réduire

1. Retirer ce qui ne sert plus. Cela coûte peu et ne comporte aucun risque.
2. Différer ce qui sert mais pas immédiatement : un composant qui se charge quand quelqu'un l'utilise ne pèse pas sur l'ouverture.
3. Réduire le poids de ce qui reste, en commençant par les images, qui en sont presque toujours la part la plus lourde.
4. Changer la manière dont le site est construit. C'est le dernier point car c'est le seul qui exige un projet, et les trois premiers ont déjà donné l'essentiel du résultat.

Quand la lenteur n'est pas le problème à résoudre

• Si cela ralentit seulement depuis votre bureau, le soupçon se porte sur le réseau interne ou la connexion sécurisée, pas sur le site.
• Si le temps s'écoule avant que le navigateur ne reçoive quoi que ce soit, le problème se situe au niveau du serveur ou de la fonction qui prépare la page : un catalogue avec une recherche lourde ne se résout pas en compressant des images.
• Si la page lente est une page que presque personne ne visite, l'intervention est réelle mais inutile.
• Si l'attente dépend de quelque chose qui travaille réellement, par exemple un calcul ou un configurateur, on travaille sur l'attente : indiquer que quelque chose est en train de se passer et où cela en est.

Ce que ce guide ne couvre pas

Il est ici question de l'expérience technique : ce qui rend l'usage du site pénible et comment le mesurer de façon reproductible. On ne promet pas qu'un meilleur score apporte un meilleur classement ou davantage de demandes, car cela ne fonctionne pas ainsi. La liste complète des contrôles à faire avant de publier un nouveau site est un autre sujet, tout comme le diagnostic des demandes qui n'arrivent pas.