Analyser son temps de chargement avec Google PageSpeed

L’optimisation de la vitesse d’un site est une question très épineuse. Et pour cause, cette problématique repose sur des dizaines, voire des centaines, de facteurs. Plus encore, les outils à disposition pour ce type d’analyses offrent des résultats variables. 

Ajoutez à cela le fait que la plupart des chiffres qu’on obtient sont temporels (ils sont obtenus à un moment t, lorsque votre serveur est à x % de sa capacité) et parfois difficiles à interpréter. Les développeurs auxquels vous parlerez durant ce type d’exercices refroidiront sans doute vos ardeurs : il est rare que vous ayez la possibilité d’optimiser la totalité des sphères qui entrent en jeu. Par exemple, les scripts des ressources chargées, dont des APIs et librairies externes, tels que Google Analytics, échapperont la majorité du temps à votre rayon d’action.

Bien heureusement, ce ne sont pas les outils qui manquent pour auditer la vitesse de chargement d’un site. Notons que ceux-ci s’intéressent très majoritairement au temps de chargement de chaque page d’un site. Et pour cause, leur contenu a un énorme impact sur leur rapidité à s’afficher, même si elles ont un tronc commun : les performances du serveur et les ressources chargées pour le fonctionnement du site Web.

Notez que d’un outil à l’autre, vous pourriez obtenir des données et des recommandations qui varient. Outre le fait que ces tests soient temporels, ce phénomène est lié à l’algorithme que chacun d’entre eux utilisent, aux paramétrages qu’ils proposent (réseaux et types d’appareils, par exemple), mais aussi la localisation des serveurs utilisés pour ces tests.

GTmetrix pour tester votre site internet

GTmetrix occupe une place particulière parmi ces outils. C’est tout d’abord l’un des plus anciens, mais c’est aussi et surtout celui le plus utilisé (parmi les experts Marketing qui s’intéressent à la vitesse, mais aussi les développeurs).

Disponible gratuitement (une version payante est proposée avec des fonctionnalités non offertes en gratuit), il fournit une analyse très complète du chargement d’une page sur Desktop, en utilisant de nombreux serveurs dans le monde. En plus d’offrir des données tirées des outils Page Speed Insights de Google et YSlow, il fournit le détail en Waterfall du séquençage de chargement de chaque ressource appelée lors de l’affichage d’une page.

GTmetrix a, de plus, le mérite d’offrir des rapports en PDF que vous pouvez transmettre à votre équipe de développement.

Attention toutefois, cet outil ne permet pas (dans sa version gratuite) de mener d’analyses sur mobile, ce qui est une vraie limite.

Page Speed Insights et Lighthouse pour tester vos pages

Cela fait des années que Google pousse pour des sites Web toujours plus rapides. Ce n’est donc pas une surprise si le géant de la recherche a développé ses propres outils pour aider les développeurs à améliorer les plateformes Web sur lesquelles ils travaillent.

PageSpeed Insights est l’un d’eux. Il existe depuis 2010 et est lui aussi très largement utilisé. L’outil se veut simplifié et permet d’analyser les performances d’une page sur mobile et Desktop. Il offre des données en temps réel. Son principal désavantage est qu’il ne permet pas de générer des rapports (à télécharger) aussi simplement que GTmetrix.

Lighthouse est l’autre principal outil développé par Google pour aider la communauté à créer des sites Web plus rapides. Il est très similaire à PageSpeed Insights, mais il ne se limite pas à la performance et on y accède en utilisant les outils pour développeurs dans Chrome (section “Audits” dans la barre de console du navigateur).

Performances throttling

Ouvrons une petite parenthèse concernant les outils qui permettent de simuler le chargement sur certains appareils ou réseaux (c’est notamment le cas des outils de Google). Pour permettre ce type d’analyses, ceux-ci font du “throttling”, c’est à dire qu’ils simulent une vitesse de traitement des données (processeur) et/ou de réception de celles-ci (réseau) similaire à celle visée en les limitant artificiellement. 

Ce procédé est imparfait, puisqu’il ne représente pas nécessairement la réalité. Mais c’est mieux que rien ! Plus encore, nous avons tendance à penser que l’algorithme utilisé par Google avec ses deux outils principaux doit être proche de celui utilisé par ses robots pour évaluer la performance d’une page. Il faut donc s’y fier.

Comment mener son analyse de vitesse de chargement

Encore une fois, l’analyse des performances d’un site est très complexe. Vous devez donc tenter d’être cohérent et organisé dans votre méthodologie. Tout d’abord, tentez d’utiliser les mêmes outils lors de vos analyses comparatives. Les données peuvent être très fortement impactées par vos choix, mieux vaut donc garder de la cohérence à cet égard.

Nous vous conseillons, par ailleurs, d’effectuer une analyse pour le mobile, et une autre pour le Desktop. Les statistiques et les recommandations que vous en tirerez vont varier, et du fait de l’index mobile déployé par Google, il est très important que vous tentiez d’optimiser les pages analysées pour chaque type d’appareils.

Dans la même logique, effectuez vos tests de vitesse pour toutes les sortes de pages clés (sur mobile et Desktop), car les résultats obtenus vont là aussi fortement fluctuer suivant les sortes de contenus proposés. Les pages très riches en images, vidéos, ressources interactives… vont, par exemple, être bien plus problématiques.

Autre conseil : focalisez-vous avant tout sur les points d’optimisation les plus critiques. La plupart des outils vous donnent des indications à cet égard. GTmetrix fournit, par exemple, une priorité pour chaque point analysé, ainsi que le niveau de gravité des résultats obtenus. Ainsi, un point crucial (comme la compression des images) pour lequel l’analyse a retourné des résultats médiocres devront être traités en priorité.

Par ailleurs, tentez d’évacuer de votre analyse (ou de mettre de côté) les points qui concernent des ressources essentielles hors du contrôle des développeurs. Les scripts de Google Tag Manager et Google Analytics sont, par exemple, généralement pointés du doigt comme bloquant l’affichage des pages. Mais ces scripts doivent être chargés le plus vite possible et sont indispensables pour utiliser ces outils. Il n’y a donc pas grand chose qui peut être fait à leur égard.

Aussi, travaillez toujours AVEC les développeurs qui doivent appliquer vos recommandations. Ils ont généralement une meilleure connaissance de la plateforme que vous tentez d’optimiser et sauront rapidement ce qui est faisable, comment et en combien temps. Ils sont donc la pierre angulaire dans le cadre de ces efforts. Vous devez les intégrer dans votre démarche en leur expliquant les tenants et les aboutissants de votre approche. Donnez-leur le plus de détails possibles et expliquez-leur le pourquoi du comment. Ainsi, ils vous accompagneront mieux et seront plus motivés à le faire.

Enfin, pensez aussi aux personnes qui s’occupent du contenu du site. En effet, les développeurs ne sont pas les seuls qui ont un impact sur le temps de chargement d’un site. La plupart du temps, ce sont les images qui plombent ces performances, d’où l’importance d’adresser des recommandations et d’éduquer les individus qui créent et entrent le contenu de la plateforme en question.

Si vous utilisez GTmetrix, vous allez vous concentrer sur le temps de chargement complet de la page, ainsi que le poids de celle-ci et le nombre de ressources chargées. Vous allez ensuite analyser chaque point à améliorer.

D’autres outils, comme Page Speed Insights, vont cependant vous fournir d’autres métriques clés pour l'analyse de la performance d’une page. Ceux-ci vont vous aider à mieux comprendre où les problèmes constatés sont les plus graves, mais aussi à quel point cela impacte l’usage du site. Le délai avant qu’une page devienne interactive est, par exemple, crucial pour l’expérience utilisateur.

Le poids de la page web

Selon les statistiques fournies par GTmetrix (basées sur les pages analysées lors des 30 derniers jours au 10 mars 2020), le poids moyen d’une page est de 3,23 MB.

Pourquoi est-ce un facteur important pour la vitesse de chargement d’une page ? Parce que plus une page est lourde, plus les navigateurs (et robots) mettent du temps à la télécharger et l’afficher. Plus elle pèse lourd, plus elle requiert des ressources.

Il est donc important de tenter d’atteindre un poids maximal qui soit le plus bas possible.

Le nombre de requêtes effectuées

Lorsqu’une page est chargée, des requêtes sont faites pour appeler les ressources nécessaires à l’affichage du contenu qu’elle comprend. Par exemple, si vous affichez une carte en utilisant Google Maps, une requête va être envoyée à ce dernier. Si vous utilisez des polices de caractères proposées par Google (Google Fonts), là encore, une (ou plusieurs) requête va être envoyée aux serveurs de Google pour les charger. Notons qu’une requête peut être faite pour une ressource interne (JavaScript, CSS, HTML, etc.) ou externe (API, librairie…).

Vous l’aurez compris, plus le nombre de requêtes est élevé, plus le temps de chargement risque d’être long. Et ce parce qu’effectuer des requêtes a un coût en termes de ressources et de temps, mais aussi parce que celles-ci vont souvent dépendre de serveurs externes (qui reçoivent généralement des centaines, voire des milliers de requêtes au même moment).

Idéalement, il faut donc limiter le nombre de requêtes effectuées lors du chargement d’une page. Selon les statistiques fournies par GTmetrix (basées sur les pages analysées lors des 30 derniers jours au 10 mars 2020), le nombre moyen de requêtes fait est de 88.

Le Time To First Byte (TTFB) ou le moment où les premières données sont reçues

Cet indicateur n’est pas toujours fourni par les outils de performances, mais est très important et souvent utilisé comme référence. Le Time To First Byte (TTFB) renvoie au moment où le navigateur reçoit les premières données de la part du site qu’il a sollicité. Il s’agit d’un instant critique dans le cycle de chargement d’une page, car plus le laps de temps entre l’envoi de la requête et la réception d’une réponse est long, plus la vitesse de chargement de la page va être mauvaise.

Le Time To First Byte est souvent un indicateur intéressant pour juger de la performance d’un serveur. Notons que ni GTmetrix, ni Page Speed Insights (ou Lighthouse) ne donnent cette donnée. Le premier offre cependant une vue en cascade du séquençage de chargement d’une page qui permet de voir quand le premier élément est reçu.

Start Render, quand le navigateur affiche (enfin) le contenu

Un autre indicateur très important, cette fois-ci pour l’usager, est le Start Render, c’est à dire le moment durant lequel un navigateur va commencer à afficher du contenu (après avoir reçu du code du site Web sollicité et l’avoir converti en éléments visuels). Là encore, cet instant doit arriver le plus tôt possible, car il n’y a rien de pire que de laisser un utilisateur devant une page blanche. Il est très important que des éléments visuels soient affichés au plus vite pour au moins faire patienter les visiteurs et les pousser à rester.

Notons que Page Speed Insights procure le First Contentful Paint, un indicateur qui a la même essence puisqu’il s’intéresse au moment où le navigateur affiche les premiers contenus (textes ou images) d’une page.

Visually Complete, l’instant où tout le contenu est visible

Lorsque le navigateur a reçu le code et les éléments à charger nécessaires à l’affichage de la page, il construit cette dernière pour la montrer. Comme nous l’avons vu, ce processus est rythmé par plusieurs étapes. L’indicateur Visually Complete renvoie au moment où tout ce contenu est affiché.

Il s’agit d’un critère relativement important, puisqu’il permet de savoir quand une page est finalement complètement construite dans le navigateur. Mais ce moment est peut-être moins significatif que le Time To First Byte, le Start Render et celui durant lequel une page devient interactive, du moins pour l’usager.

Cet indicateur n’est pas fourni par GTmetrix ou Page Speed Insights.

Document Complete : le document est complètement chargé

Si une page est complètement affichée dans un navigateur, cela ne veut pas dire qu’elle est complètement chargée. L’étape du Document Complete intervient lorsque le document HTML est totalement chargé.

Cet indicateur, qui n’est pas ourni par GTmetrix ou Page Speed Insights, n’est pas non plus le plus crucial, car ce n’est pas à cette étape-ci que la page est encore intéractive. Cependant, entre le TTFB et le fait qu’une page soit interactive, il est important de savoir si l’usager attend longtemps pour voir la page dans sa forme finale. Si ce laps de temps est trop important, cela peut le pousser à s’en aller.

Fully Loaded et Time to Interactive, page complètement chargée et intéractive

Autre point très important, ce n’est pas parce qu’une page est affichée dans sa totalité qu’elle devient interactive (c’est à dire parfaitement utilisable). C’est pourquoi les indicateurs Fully Loaded (page complètement chargée, avec toutes ses ressources JavaScript et autres) et Time to Interactive (quand la page est complètement interactive, soit quand le visiteur peut l’utiliser complètement) sont très importants.

D’un point de vue UX avant tout, ce moment doit arriver le plus vite possible. Avez-vous déjà accédé à une page qui ne répond pas pendant plusieurs secondes ? C’est très frustrant !

Les scores propres à chaque outil

La plupart des outils de performance, dont GTmetrix (avec des notes) et Page Speed Insights (avec un indicateur sur 100), fournissent leur propre score. Ces indicateurs servent à donner une idée générale quant à la performance d’un site et à comparer entre plusieurs sites.

Ils ne doivent toutefois pas être utilisés comme une référence absolue, sans contexte. Il nous est souvent arrivé de voir des sites avec de très bons scores, mais de très mauvaises performances. Ces notes sont en fait fixées sur une liste d’optimisations à effectuer. Pour atteindre les meilleurs niveaux, il faut remplir le maximum de ces conditions. Mais, cela ne veut aucunement dire que les performances sont véritablement bonnes - car il est possible que tout soit mis en place pour obtenir de bons résultats, mais que ce ne soit pas le cas en réalité.