PAGESPEED

Analyse des performances et des données vitales du Web pour améliorer le classement dans les moteurs de recherche.

Vue d’ensemble
Pagespeed Insight

Aujourd’hui, la performance d’un site web est essentielle pour le positionnement organique dans le Serp de Google, et cette tendance est encore plus corroborée par les nouvelles Vitales Web de base qui sont devenues un facteur de classement à partir de mai 2021.

L’onglet “PageSpeed” de Seo Spider vous permet de collecter des données à partir de deux sources :

  • PageSpeed Insights, qui utilise Lighthouse pour vérifier la vitesse des pages web à l’aide de “données de laboratoire” ;
  • Chrome User Experience Report (CrUX, ou “données de terrain”) qui vous permet d’obtenir des données de navigation réelles.

Pour alimenter les données de l’onglet “PageSpeed”, l’API PSI doit être connectée.

> > Configuration API PageSpeed Insights

Les mesures

Dans l’onglet Pagespeed, vous disposez de plusieurs mesures génériques :

  • Économies totales de taille.
  • Gain de temps total.
  • Total des demandes.
  • Taille totale de la page.
  • HTML Taille.
  • Compte HTML.
  • Taille de l’image.
  • Nombre d’images.
  • CSS Taille.
  • Compte CSS.
  • JavaScript Taille.
  • Compte JavaScript.
  • Taille de la police.
  • Nombre de polices.
  • Taille du support.
  • Nombre de médias.
  • Autre taille.
  • Autre compte.
  • Tiers Taille.
  • Compte de tiers.

Les mesures plus spécifiques disponibles sont réparties entre “CrUX Metrics”, qui correspond aux données de Chrome sur le terrain, et “Lighthouse Metrix”, qui contient les données de laboratoire publiées par PageSpeed Insight.

CrUX Metrics

  • CrUX Performance.
  • CrUX First Contentful Paint Time (sec).
  • CrUX First Contentful Paint Catégorie.
  • CrUX First Input Delay Time (sec).
  • CrUX First Input Delay Catégorie.
  • CrUX Origin Performance.
  • CrUX Origin First Contentful Paint Time (sec).
  • CrUX Origin First Contentful Paint Catégorie.
  • CrUX Origin First Input Delay Time (sec).
  • CrUX Origin First Input Delay Category.

Lighthouse Metrics

  • Score de performance.
  • Temps d’accès au premier octet (ms).
  • Premier temps de peinture du contenu (sec).
  • Vitesse Index Temps (sec).
  • Temps d’interactivité (sec).
  • Première note de peinture de contenu.
  • Premier temps de peinture significatif (sec).
  • Premier score significatif en peinture.
  • Score de l’indice de vitesse.
  • Estimation de la latence d’entrée (ms).
  • Score de latence d’entrée estimé.
  • Première période d’inactivité de l’unité centrale (sec).
  • Premier score d’inactivité de l’unité centrale.
  • Temps nécessaire pour obtenir un score interactif.

Filtres Pagespeed

En plus des mesures, l’onglet comprend les filtres suivants :

  • Supprimer les ressources bloquant le rendu: toutes les pages dont les ressources bloquent la “première peinture” de la page sont affichées, ainsi que les économies potentielles.
  • Images de taille correcte: le filtre met en évidence toutes les pages qui contiennent des images de taille incorrecte et souligne les économies potentielles si elles sont corrigées.
Web Vitals - gestione delle dimensioni delle immagini

Idéalement, votre page web ne devrait pas afficher d’images plus grandes que la version affichée sur l’écran de l’utilisateur. La stratégie la plus appropriée est de servir des “images réactives” en générant plusieurs versions et en spécifiant lesquelles utiliser dans votre code HTML ou CSS via des requêtes média, la taille de la fenêtre, etc.

D’autres solutions peuvent être l’utilisation de CDN d’images ou l’utilisation de formats d’images vectorielles SVG pour s’adapter à n’importe quelle taille, par exemple pour les icônes.

  • Différer les images hors écran: identifie toutes les pages qui contiennent des images cachées ou hors écran, ainsi que les économies potentielles. Pour résoudre ce problème, vous pouvez envisager de charger ces images paresseusement après les ressources critiques afin de réduire l’indice “Time to Interactive”.
  • Minify CSS: toutes les pages dont les fichiers CSS n’ont pas été minifiés, ainsi que les économies potentielles si ces fichiers avaient été correctement minifiés.
Core Web Vitals - gestione della minificazione dei Css

La minimisation des feuilles de style CSS améliore le temps de chargement des pages, car les feuilles de style CSS utilisées sont généralement plus volumineuses que ce qui est nécessaire. Les fichiers CSS peuvent contenir des caractères inutiles, tels que des commentaires, des espaces blancs et des indentations.

Lorsqu’elles sont mises en ligne, ces polices peuvent être supprimées en toute sécurité pour réduire la taille du fichier sans affecter la manière dont le navigateur traite les styles. Cette technique est appelée minification.

Esempio del codice Css da minificare

Ce code peut être réduit en une seule ligne :

  • Minify JavaScript: affiche toutes les pages dont les fichiers JavaScript n’ont pas été minifiés, ainsi que les économies potentielles. La minimisation des fichiers JavaScript permet de réduire la taille de la charge utile et le temps d’analyse des scripts.
    La minification consiste à supprimer les espaces blancs et tout code inutile afin de créer un fichier de code plus petit mais parfaitement valide. Par exemple, Terser est un outil de compression JavaScript très répandu. webpack v4 inclut par défaut un plugin pour cette bibliothèque afin de créer des fichiers de construction minifiés.
  • Supprimer les feuilles de style CSS inutilisées : identifie les pages contenant des feuilles de style CSS inutilisées, ainsi que les économies potentielles en octets. Les développeurs l’utilisent généralement pour ajouter des feuilles de style à une page :
file css esterno

Le fichier main.css que le navigateur télécharge est appelé feuille de style externe et est stocké séparément du code HTML qui l’inclut. Ainsi, chaque fois qu’un navigateur rencontre cette condition, il doit télécharger, analyser et traiter toutes les feuilles de style externes qu’il rencontre avant de pouvoir afficher un contenu sur l’écran de l’utilisateur.

  • Encoder efficacement les images : le filtre affiche les pages dont les images ne sont pas optimisées, ainsi que les économies potentielles. Lighthouse rassemble toutes les images JPEG ou BMP de la page, règle le niveau de compression de chaque image sur 85, puis compare la version originale avec la version compressée. Si l’économie potentielle est de 4 KiB ou plus, Lighthouse marque l’image comme étant optimisable.
  • Serve Images in Next-Gen Formats: met en évidence les pages dont les images sont servies dans des formats plus anciens tels que jpeg et png. Il est conseillé d’utiliser des formats tels que AVIF et WebP, qui présentent des caractéristiques de compression et de qualité supérieures.
  • Activer la compression de texte : toutes les pages contenant des ressources textuelles qui n’ont pas été compressées, ainsi que les économies potentielles.
  • Préconnexion à l’origine requise: le filtre identifie toutes les pages qui sont connectées à d’autres domaines que le vôtre, mais qui ne donnent pas encore la priorité aux demandes de recherche avec des liens rel=preconnect, ainsi que les économies potentielles. Avant de demander une ressource à un serveur, le navigateur doit établir une connexion avec le serveur pour rechercher le nom de domaine et le définir dans une adresse IP, pour établir une connexion avec le serveur et pour crypter la connexion. Au cours de toutes ces étapes, le navigateur envoie des données et reçoit des réponses du serveur. Ce processus est appelé “aller-retour” et, en fonction des conditions du réseau, prend du temps, ce qui affecte inexorablement les performances.

Pour optimiser ce processus, vous pouvez utiliser la “préconnexion” des ressources externes (connexions à d’autres domaines) qui indique au navigateur les ressources auxquelles il doit se connecter en premier lieu parce qu’elles sont considérées comme prioritaires.

preconnect della risorsa per i web vitals

Un exemple d’application de “preconnect” pourrait être pour Google Tag Manager ou Google Analytics.

preconnect di GA e GTM per migliorare le performance dei Core Web Vitals

Les “demandes de chaîne critique” correspondent à une série de demandes de réseau dépendantes et importantes pour le rendu correct du document html.

  • Réduire les temps de réponse du serveur (TTFB) : la vitesse de chargement est essentielle pour une bonne expérience utilisateur et les utilisateurs y sont très sensibles. Le taux d’abandon d’un site qui met plusieurs secondes à se charger est directement proportionnel. L’une des causes les plus courantes est liée à la lenteur du serveur à renvoyer le contenu de la page au navigateur. Ce filtre identifie toutes les pages pour lesquelles le navigateur a dû attendre plus de 600 ms la réponse du serveur dans la requête principale du document.
  • Éviter les redirections multiples: affiche les pages qui comportent des ressources de redirection et les économies potentielles réalisées en utilisant l’URL directe. Les redirections ralentissent la vitesse de chargement des pages. Lorsqu’un navigateur demande une ressource qui a été redirigée, le serveur renvoie généralement une réponse HTTP comme celle-ci :
codice per la gestione degli reindirizzamenti

et le navigateur est obligé de faire une autre demande HTTP pour récupérer la ressource au nouvel emplacement. Cette considération n’a pas pour but de proscrire l’utilisation de 3xx mais lors de la création de chaînes de redirections ou de redirections multiples sur la même page.
Les redirections vers les ressources nécessaires au “chemin de rendu critique” doivent toujours être évitées.

  • Preload Key Requests: identifie les pages html contenant des éléments susceptibles d’être traités par “preload”.
    Lorsqu’une page est demandée, le navigateur demande la page html au serveur en analysant le contenu et en envoyant des demandes distinctes pour chaque ressource de référence incluse dans le document. Pour améliorer les performances, il est recommandé d’accélérer ce processus en demandant à l’avance les ressources critiques.
    Un exemple d’application pourrait être la demande d’une police de caractères dans un fichier CSS, puisque le navigateur ne la découvrirait qu’après avoir lu la feuille de style. En utilisant la fonction “Preload”, vous allez précharger et récupérer une ressource que le navigateur ne prendrait en compte qu’à un stade ultérieur, par exemple dans les demandes de chaîne critique.
    Rappelez-vous que le navigateur met en cache la ressource en “préchargement” sans exécuter les scripts mais, les ayant déjà pris en compte, les servira immédiatement une fois qu’ils auront été demandés.
    Cette fonctionnalité convient parfaitement aux dépendances telles que JS, les polices de caractères et CSS.

Cette fonctionnalité est une directive permettant au navigateur de ne pas bloquer le chargement du document html. <> <> Pour mettre en œuvre la directive “Preload”, il suffit d’ajouter la balise link dans la section head du fichier html ou d’utiliser l’en-tête HTTP Link.

gestione del codice con il preload per migliorare le performance dei Core Web Vitals
  • Utiliser le format vidéo pour les images animées: identifie les pages contenant des GIF animés, ainsi que les économies potentielles si elles sont converties en vidéo.
  • Éviter la taille excessive du DOM : identifie toutes les pages dont la taille du DOM dépasse les 1 500 nœuds totaux recommandés. La prise en compte des DOM est d’une importance vitale car elle peut nuire à la performance et à l’efficacité de plusieurs manières :
    • le DOM comprend souvent de nombreux nœuds qui ne sont pas visibles par l’utilisateur lorsque la page est chargée pour la première fois ; cette situation augmente inutilement le volume de données à servir aux utilisateurs et ralentit le temps de chargement (performance de chargement).
    • Au cours de la navigation, les utilisateurs et les scripts ont de nombreuses interactions avec la page web qui amènent le navigateur à réorganiser la position et le style des nœuds dans le DOM, ce qui ralentit le rendu (performances d’exécution).
    • Si JavaScript utilise des sélecteurs de requête généraux tels que document.querySelectorAll(‘li’), il peut, à son insu, stocker des références à un très grand nombre de nœuds, ce qui peut surcharger les capacités de mémoire des appareils des utilisateurs (performances de la mémoire).
  • Réduire le temps d’exécution du JavaScript: filtrez les pages de rapport dont le temps d’exécution du JavaScript est moyen ou lent. Lorsqu’une page html prend beaucoup de temps pour exécuter des scripts JavaScript, cela ralentit les performances :
    • l’augmentation du coût du réseau : l’utilisation d’un plus grand nombre d’octets augmente le temps de téléchargement.
    • Le javascript est analysé et compilé dans le fil principal, qui ne reste pas disponible pour l’interaction avec l’utilisateur.
    • L’occupation du fil Javascript principal retarde également le TTI (Time to Interactive), ce qui pénalise l’Ux de la page et les vitales dédiées au web.
    • Si le Javascript contient de nombreuses références, il peut inexorablement consommer beaucoup de mémoire, pénalisant la consultation de la page par l’utilisateur.

Pour améliorer les performances de l’exécution du Javascript, il est généralement recommandé de “minifier” et de compresser le code, de supprimer le code inutilisé et de le mettre en cache.

  • Serve Static Assets With An Efficient Cache Policy: renvoie toutes les pages contenant des ressources qui ne sont pas “mises en cache”, ainsi que les économies potentielles. Lorsqu’un navigateur demande une ressource, le serveur qui la fournit peut lui indiquer la durée pendant laquelle il doit la stocker temporairement ou la mettre en cache. Pour chaque demande ultérieure de cette ressource, le navigateur utilise sa copie locale au lieu de l’obtenir du réseau. Les évaluations de Lighthouse prennent en compte les polices, les médias, les images ou les feuilles de style qui répondent par le code d’état 2xx et qui n’ont pas explicitement déclaré une “politique de non-cache”.

Voici un exemple de mise en cache via l’en-tête HTTP :

codice per il controllo della cache di un elemento

La directive “max-age” indique au navigateur combien de temps une ressource doit rester dans le cache. Pour les “biens statiques”, un délai d’au moins un an est recommandé.

  • Minimiser le travail du thread principal: identifie toutes les pages dont le temps d’exécution sur le thread principal est moyen ou lent, ce qui pénalise le rendu du document html. Le processus de rendu du navigateur transforme votre code en une page web avec laquelle les utilisateurs peuvent interagir. Par défaut, le fil principal du processus de rendu gère la majeure partie du code : il analyse le HTML et construit le DOM, il analyse le CSS et applique les styles spécifiés, et il analyse, évalue et exécute le JavaScript.

Le fil principal traite également les événements de l’utilisateur. Ainsi, lorsque le fil principal est occupé à faire autre chose, la page web peut ne pas répondre aux interactions de l’utilisateur, ce qui entraîne une mauvaise expérience. Pour améliorer ce processus, nous vous recommandons d’optimiser le javascript des tiers, de supprimer le code inutilisé, de réduire les références CSS et de les simplifier (minification), de reporter les CSS non critiques et de diviser les charges utiles du javascript.

  • Veiller à ce que le texte reste visible pendant le chargement des polices : toutes les pages contenant des polices susceptibles de clignoter ou de devenir invisibles pendant le chargement des ressources.

Exportation des données de performance

Toutes les données de performance, les pages sources et les URL des ressources susceptibles d’être optimisées peuvent être exportées en masse via le menu PageSpeed.

> Rapports PageSpeed

Panoramica del report "Pagespeed" di Screaming Frog
Seo Spider Tab