Avec la mise à jour effectuée sur son outil PageSpeed Insights, Google indique plus clairement que jamais qu’il existe plusieurs façons et différentes valeurs pour mesurer la vitesse de chargement de sa page Web. Découvrez dans cet article une présentation approfondie des métriques les plus importantes ainsi que quelques conseils pratiques pour optimiser votre site à ce niveau-là.
Pour Google, le Page Speed revêt une importance de plus en plus grande. Au cours des derniers mois, le géant des moteurs de recherche a montré plusieurs fois comment il évaluait les sites Web lents, en particulier les sites mobile. C’est un fait intéressant, notamment dans la mesure où le dernier message officiel de Google à ce sujet date d’il y a plus de 9 ans, en 2010.
Dans la lignée de ces activités, la dernière mise à jour de l’outil interne de Google correspond à la phase de test du Page Speed. La cinquième version de PageSpeed Insights est basée sur Lighthouse, un outil d’optimisation des sites Web qui est également disponible comme extension dans le navigateur Chrome. Il utilise également les données de CrUX, le rapport sur l’expérience utilisateur de Chrome. Il devient donc clair que Google comprend la vitesse de page d’un point de vue technique, mais aussi dans le cadre d’une bonne expérience utilisateur.
Après avoir contrôlé la vitesse de votre site Web au moyen de cet outil, vous remarquez certainement que le résultat a été considérablement dégradé. Cela s’explique principalement par le fait que Google prend en compte beaucoup plus de critères pour son évaluation et teste aussi la vitesse depuis un appareil mobile à la bande passante moyenne : cela constitue désormais la base de son évaluation initiale.
Si vous n’êtes pas familiarisé avec la présentation de Lighthouse, vous remarquerez que PageSpeed Insights affiche désormais cinq valeurs différentes pour le Page Speed. Et comme si cela n’était pas assez déroutant, l’outil omet de préciser une mesure importante, qui était jusqu’alors une des métriques centrales.
Cet article est donc là pour vous expliquer les métriques les plus importantes de l’outil PageSpeed Insights ainsi que d’autres outils qui permettent aussi de tester le temps de chargement de votre page. En outre, nous vous livrerons des conseils sur la façon dont ces mesures peuvent être améliorées dans le cadre de l’optimisation de votre projet Web.
Qu’est-ce que le Page Speed ? En général, on évoque la période qui s’écoule entre le moment où un site Web est lancé et le moment où il est rendu et prêt à être visualisé dans le navigateur. Pendant ce temps, plusieurs processus complexes se déroulent, dont la durée dépend de certains facteurs. Pour déterminer et optimiser ces facteurs, des métriques supplémentaires peuvent s’avérer très utiles.
Notre top 4 de ces valeurs par ordre chronologique :
Illustration 1 : Les mesures du Page Speed par étape après le lancement d’un site Web.
Le Time To First Byte mesure la période de temps qui débute avec le lancement du site Web et se termine avec le premier octet reçu depuis le serveur Web. Dans le contexte des autres métriques présentées, le TTFB est une exception, car il mesure uniquement la requête d’un site Web et non son affichage.
Dans l’outil Website Success de Ryte, le Time To First Byte est affiché dans le rapport sur la performance. Le fait que Ryte affiche séparément une valeur supplémentaire, qui est considérée comme faisant partie du TFFB, est particulièrement intéressant : il s’agit ici du temps de connexion entre l’ordinateur de l’utilisateur et le serveur Web.
Illustration 2 : Le rapport sur la performance de Ryte.
Ce temps de connexion est très important, car les premiers facteurs d’un Page Speed lent peuvent déjà se trouver ici. Pour que la connexion au serveur Web soit réussie, l’adresse IP de ce dernier doit être déterminée via le domaine. Cela se fait en déterminant le nom de domaine via le serveur DNS jusqu’à ce que l’adresse IP soit trouvée. Le navigateur utilise ensuite l’adresse IP pour se connecter au serveur Web via différents routeurs sur Internet. Selon l’emplacement et la connexion réseau, cette connexion contient des latences qui provoquent un retard dans la transmission.
Si vous utilisez un certificat SSL – et vous devriez ! – et que la requête passe par le protocole HTTPS, le SSL handshake se produira, après quoi la connexion chiffrée sécurisée est établie. Si l’ordinateur est connecté au serveur Web, le navigateur envoie une requête via le protocole HTTP. Le logiciel du serveur Web traitera ensuite cette requête. La performance du système et l’utilisation du matériel du serveur sont décisives pour le temps de traitement.
Afin de réduire le temps de connexion, le chemin vers la résolution du domaine peut être optimisé. Le serveur de Google à l’adresse IP « 2.2.2.2” »ou le « 1.1.1.1 » de Cloudfare sont ici toujours populaires. C’est quelque chose que vous pouvez aussi clarifier avec votre fournisseur de domaine. Si, pour votre projet web, il est important d’assurer un accès à votre site dans le monde entier et dans les mêmes conditions, vous pouvez aussi utiliser un réseau de diffusion de contenu (CDN).
Un CDN peut en effet réduire la latence entre l’utilisateur et le serveur Web. Le contenu des pages Web qui peut être stocké dans un cache est mis en cache dans le CDN et peut donc être consulté plus rapidement. Certains CDN offrent des fonctions qui permettent de récupérer plus efficacement même le contenu dynamique, puisque les latences sont optimisées par le routage au sein du CDN.
Si le TTFB augmente malgré des latences optimisées, cela peut être dû à un étranglement dans l’infrastructure informatique ou à un serveur Web surchargé. Il vous reste alors à contacter votre administrateur système ou votre hébergeur. Le changement du logiciel du serveur Web peut également avoir un effet positif sur le TTFB.
Après le premier octet suivent toutes les autres données du site Web, y compris le code HTML, les feuilles de style et les fichiers script, les polices de caractères et surtout les fichiers multimédia, comme les images et les vidéos. Le First Contentful Paint mesure le moment auquel le navigateur est capable de rendre un élément de page à l’écran pour la première fois. C’est important pour l’utilisateur car il reçoit un retour positif que le site est effectivement chargé.
Dans l’outil Pagespeed Insights, la valeur du FCP est présentée comme la première étape de mesure, au lieu du TTFB. C’est logique pour l’outil de Google, car il est destiné aux développeurs et propose principalement des mesures d’optimisation OnPage.
Illustration 3 : Capture d’écran de l’outil Page Speed Insights (Laboratoire de données).
Le volume de téléchargement du site Web est important pour un affichage rapide dans le navigateur. Plus cette taille est importante, plus la transmission prend du temps. En plus de la latence, un code source non compressé gonflé de commentaires et de grandes bibliothèques de scripts peut également augmenter le temps de transfert et ralentir la vitesse générale du site. Bien que la bande passante n’ait aucune influence sur la latence, elle est décisive pour la vitesse de transmission et devient de plus en plus importante avec l’augmentation de la taille du site.
Les fichiers script sont divisés en CSS et JavaScript. CSS est responsable de l’affichage des éléments HTML dans le navigateur, de sorte que le navigateur bloque le rendu du site Web jusqu’à ce que les CSS soient entièrement chargés. JavaScript est nécessaire pour la fonctionnalité et le contrôle interactif du site Web du côté de l’utilisateur. L’affichage du site Web ne commence pas avant que le démarrage JavaScript n’ait lieu.
Un transfert rapide et structuré des données du site du serveur Web au navigateur est important. Afin de maintenir le volume de téléchargement à un faible niveau, les données peuvent être compressées par GZIP ou Brotli. HTTP/2 (aussi appelé H2) peut être activé dans le serveur Web pour une transmission plus rapide et des téléchargements en parallèle grâce à des connexions permanentes. La condition préalable est un certificat SSL, mais comme déjà mentionné, vous devez en principe déjà l’utiliser. Ces certificats sont par ailleurs gratuits avec Let’s Encrypt. Veuillez contacter votre hébergeur ou l’administrateur système si le changement est encore possible.
Pour ne pas avoir à demander à nouveau tout le contenu du serveur Web lorsque vous rechargez un site Web ou chargez une page secondaire avec un contenu similaire, vous pouvez utiliser une mise en cache HTTP intelligente pour déterminer combien de temps certains éléments doivent être mis en cache sur l’ordinateur de l’utilisateur.
En spécifiant des fichiers CSS pour certains viewports, vous pouvez réduire le bloc de rendu pour ces fichiers CSS spécifiés. Les bibliothèques JavaScript et CSS peuvent souvent être personnalisées pour télécharger uniquement le contenu dont vous avez besoin, et non le contenu dans son intégralité et à chaque fois.
Dès que tout le contenu de la page pour la position actuelle du viewport a été chargé, l’utilisateur a le sentiment que la page a été chargée. Comme déjà décrit dans Ryte Magazine, il s’agit d’une étape importante. Bien que les éléments interactifs ne sont pas encore chargés et que les autres éléments « en-dessous du pli » ne sont pas encore disponibles, le processus de chargement pour l’utilisateur se termine ici.
Dans l’outil PageSpeed Insights, le FMP est décrit comme « premier passage significatif ». La transition du First Content Paint au First Meaningful Paint est clairement visible dans la capture d’écran du site Web, qui est affichée sous les valeurs mesurées. Visuellement, rien ne change ici avant le Time To Interactive. C’est pourquoi l’optimisation du FMP est d’autant plus importante.
Outre le code source et les fichiers script, les fichiers multimédia sont aussi transférés. Les images représentent près de la moitié du volume de téléchargement d’un site Web moderne. Pour les boutiques en ligne, c’est beaucoup plus. Par conséquent, un nombre élevé d’images à haute résolution peut énormément ralentir la vitesse de la page.
Ceci a un effet sur le First Meaningful Paint, car l’affichage de ces images est décisif pour la perception que le site Web est entièrement chargé. Le First Meaningful Paint peut être inutilement allongé, en particulier dans les aperçus de produits où beaucoup d’images ne sont visibles pour l’utilisateur qu’après avoir fait défiler toute la page.
Afin d’aligner l’optimisation du site Web avec les besoins de l’utilisateur, l’optimisation des images est essentielle. Dans le Ryte Magazine a déjà été abordée l’optimisation des images dans le processus de création. Pour les boutiques en ligne, qui recensent des milliers d’images de produits et des pages web avec de nombreux contenus éditoriaux, cela peut cependant devenir très complexe. La meilleure façon de traiter le problème est donc de passer par une optimisation automatisée des images.
Pour les aperçus de produits et autres sites Web qui n’affichent leurs nombreuses images qu’après avoir fait défiler la page, nous recommandons une intégration dynamique par le biais d’un Lazy Loading. Cela signifie que les images ne sont requises par le serveur que lorsqu’elles doivent effectivement être affichées sur le viewport. Entre-temps, des espaces réservés et des indicateurs de progression sont affichés pour que la mise en page ne soit pas modifiée et que l’utilisateur remarque que les images sont en cours de chargement. Avec l’outil de wao.io, le Lazy Loading peut être configuré automatiquement pour les sites Web.
La dernière mesure est celle qui indique que le site Web est chargé et prêt à interagir. La plupart des tests de Page Speed utilisent cette valeur comme base d’analyse.
Si vous avez pris en compte tous les problèmes décrits et mis en œuvre les mesures correspondantes, en particulier celles liées au First Contentful Paint et du First Meaningful Paint, il y a de bonnes chances que la valeur de votre TTI soit satisfaisante.
Nous avons comparé les 4 premières métriques utiles à la détermination du Page Speed d’une page ainsi que souligné les bloqueurs de performance, avant de présenter les solutions possibles pour l’optimisation de chacune de ces valeurs. Il s’avère que le Page Speed ne peut pas être mesuré comme une seule et unique métrique. Les différentes étapes mesurées, du lancement de la page jusqu’à sa finition, ont chacune leur propre signification pour l’être humain et la machine.
Les observations les plus importantes des métriques présentées sont résumées ici :
Time to First Byte :Site Web trop lent ?
Essayez Website SuccessÉcrit le 09.04.2019 par Roland Guelle.
En tant que directeur de Sevenval Technologies, fondée en 1999, Roland Guelle est responsable de la recherche et du développement. Avec environ 170 employés à Cologne et à Berlin, Sevenval s'est spécialisé dans les solutions frontend qui permettent une expérience utilisateur moderne, rapide et surtout sécurisée, basée sur des paysages de systèmes informatiques évolués. Aujourd’hui encore, Roland programme et aime prendre la parole lors de conférences de développeurs.
Suivi, analyse et optimisation de vos actifs numériques grâce à notre technologie unique
S’inscrire gratuitement