PageSpeed.

Vue d’ensemble de PageSpeed Insights

Aujourd’hui, les performances d’un site sont vitales pour le classement organique dans les SERP de Google, une tendance renforcée par les Core Web Vitals (LCP, INP et CLS), devenus facteurs de classement en 2021.

L’onglet « PageSpeed » de SEO Spider t’aide à collecter des données de deux sources :

• PageSpeed Insights, qui utilise Lighthouse pour mesurer la vitesse des pages avec des « données de laboratoire » ;
• le Chrome User Experience Report (CrUX, ou « données de terrain »), qui fournit des données de navigation réelles.

Pour remplir l’onglet « PageSpeed », il faut connecter l’API PSI depuis 1Configuration›2API Access›3PageSpeed Insights.

123

1Account InformationL’onglet pour connecter l’API.2Secret KeyLa clé API créée dans la Google Cloud Console.3ConnectConnecte SEO Spider à l’API.

Les métriques

L’onglet PageSpeed propose plusieurs métriques générales :

• Total Size Savings.
• Total Time Savings.
• Total Requests.
• Total Page Size.
• HTML Size.
• HTML Count.
• Image Size.
• Image Count.
• CSS Size.
• CSS Count.
• JavaScript Size.
• JavaScript Count.
• Font Size.
• Font Count.
• Media Size.
• Media Count.
• Other Size.
• Other Count.
• Third Party Size.
• Third Party Count.

Des métriques plus précises se répartissent entre les « CrUX Metrics », données de terrain de Chrome, et les « Lighthouse Metrics », données de laboratoire de PageSpeed Insights.

Métriques CrUX

Pour chaque métrique, tu as la valeur et la catégorie (Good, Needs Improvement, Poor), pour l’URL et pour toute l’origine :

• CrUX Performance.
• CrUX Largest Contentful Paint Time (sec).
• CrUX Interaction to Next Paint (ms).
• CrUX Cumulative Layout Shift.
• CrUX First Contentful Paint Time (sec).
• CrUX Time to First Byte (ms).
• CrUX Origin Performance et les mêmes métriques pour l’origine.

Depuis le 12 mars 2024, l’INP a remplacé le First Input Delay (FID) parmi les Core Web Vitals.

Métriques Lighthouse

• Performance Score.
• Time to First Byte (ms).
• First Contentful Paint Time (sec) et Score.
• Speed Index Time (sec) et Score.
• Largest Contentful Paint Time (sec) et Score.
• Total Blocking Time (ms) et Score.
• Cumulative Layout Shift et Score.

Le Total Blocking Time est l’indicateur de laboratoire de l’INP, impossible à mesurer sans interactions réelles. Des métriques comme Time to Interactive, First Meaningful Paint, First CPU Idle et Estimated Input Latency ont été retirées de Lighthouse.

Les filtres PageSpeed

En plus des métriques, l’onglet comprend les filtres suivants :

• Eliminate Render-Blocking Resources : affiche toutes les pages avec des ressources qui bloquent le « First Paint », avec le gain potentiel.
• Properly Size Images : met en évidence les pages avec des images mal dimensionnées et le gain de données possible si elles étaient corrigées.

123

1Gain de temps9,77 secondes estimées.2ImagesLes ressources à redimensionner.3Potential SavingsLes Ko économisés pour chaque image.

Idéalement, ta page ne devrait pas servir d’images plus grandes que leur affichage à l’écran. La meilleure stratégie consiste à servir des « images responsives » en générant plusieurs versions et en indiquant laquelle utiliser dans ton HTML ou ton CSS via les media queries, la taille du viewport, etc.

D’autres solutions : utiliser un CDN d’images ou des formats vectoriels SVG qui s’adaptent à toutes les tailles, pour les icônes par exemple.

• Defer Offscreen Images : identifie les pages avec des images masquées ou hors écran, avec le gain potentiel. Pour y remédier, pense au « lazy-loading » de ces images après les ressources critiques, pour réduire le « Time to Interactive ».
• Minify CSS : toutes les pages avec des fichiers CSS non minifiés, avec le gain potentiel s’ils étaient minifiés.

12

1Fichier CSSLa feuille de style non minifiée.2Potential SavingsLes Ko économisés grâce à la minification.

Minifier le CSS améliore le temps de chargement, car le CSS utilisé est généralement plus lourd que nécessaire. Les fichiers CSS peuvent contenir des caractères inutiles comme les commentaires, les espaces et l’indentation.

À la mise en ligne, ces caractères peuvent être supprimés sans risque pour réduire la taille du fichier sans changer la façon dont le navigateur traite les styles. C’est ce qu’on appelle la minification.

/* Header background should match brand colors. */
h1 {
  background-color: #000000;
}
h2 {
  background-color: #000000;
}

Ce code peut être minifié sur une seule ligne :

h1,h2{background-color:#000000}

• Minify JavaScript : affiche toutes les pages avec des fichiers JavaScript non minifiés, avec le gain potentiel. Minifier les fichiers JavaScript peut réduire la taille du payload et le temps d’analyse du script.
  La minification consiste à supprimer les espaces et tout code non nécessaire pour obtenir un fichier plus léger mais parfaitement valide. Terser, par exemple, est un outil de compression JavaScript très utilisé. webpack v4 inclut par défaut un plugin pour cette bibliothèque afin de créer des fichiers de build minifiés.
• Remove Unused CSS : identifie les pages avec du CSS inutilisé, avec le gain potentiel en octets. Les développeurs ajoutent généralement les feuilles de style d’une page ainsi :

<!doctype html>
<html>
<head>
  <link href="main.css" rel="stylesheet">

Le fichier main.css téléchargé par le navigateur est une feuille de style externe, stockée séparément du HTML qui l’appelle. Chaque fois que le navigateur rencontre ce cas, il doit télécharger, analyser et traiter toutes les feuilles de style externes avant d’afficher quoi que ce soit à l’écran.

• Efficiently Encode Images : affiche les pages avec des images non optimisées, avec le gain potentiel. Lighthouse collecte toutes les images JPEG ou BMP de la page, règle leur niveau de compression à 85, puis compare l’original et la version compressée. Si le gain potentiel atteint 4 Kio ou plus, Lighthouse signale l’image comme optimisable.
• Serve Images in Next-Gen Formats : met en évidence les pages avec des images dans d’anciens formats comme JPEG et PNG. Le conseil est d’utiliser des formats comme AVIF et WebP, aux meilleures qualités de compression.
• Enable Text Compression : toutes les pages avec des ressources textuelles non compressées, avec le gain potentiel.
• Preconnect to Required Origin : identifie toutes les pages qui se connectent à d’autres domaines que le tien sans encore prioriser les requêtes avec link rel=preconnect, avec le gain potentiel. Avant de demander une ressource à un serveur, le navigateur doit établir une connexion : résoudre le nom de domaine en adresse IP, ouvrir la connexion au serveur et la chiffrer. À chaque étape, il envoie des données et reçoit des réponses ; c’est ce qu’on appelle un « aller-retour » (round trip) qui, selon le réseau, prend du temps et pèse inévitablement sur les performances.

Pour l’optimiser, tu peux utiliser le « preconnect » des ressources externes (connexions vers d’autres domaines), qui indique au navigateur à quelles ressources se connecter en priorité.

<head>
  <link rel="preconnect" href="https://domaine.com">
</head>

<!-- La même indication peut passer par l’en-tête HTTP -->
Link: <https://domaine.com>; rel=preconnect

On peut par exemple utiliser le « preconnect » pour Google Tag Manager ou Google Analytics :

Link: <https://www.google-analytics.com>; rel=preconnect; crossorigin
Link: <https://www.googletagmanager.com>; rel=preconnect; crossorigin

Les « critical request chains » sont des séries de requêtes réseau dépendantes, importantes pour le bon rendu du document HTML.

• Reduce Server Response Times (TTFB) : la vitesse de chargement est essentielle pour une bonne expérience, et les utilisateurs y sont très sensibles. Un site qui met plusieurs secondes à charger a des taux d’abandon en proportion. L’une des causes les plus fréquentes : des réponses serveur lentes pour renvoyer le contenu de la page. Ce filtre identifie toutes les pages où le navigateur a attendu plus de 600 ms la réponse du serveur pour le document principal.
• Avoid Multiple Redirects : affiche les pages avec des ressources qui redirigent, et le gain potentiel en utilisant l’URL directe. Les redirections ralentissent le chargement. Quand un navigateur demande une ressource redirigée, le serveur renvoie en général une réponse HTTP comme celle-ci :

HTTP/1.1 301 Moved Permanently
Location: /path/to/new/location

et le navigateur doit faire une nouvelle requête HTTP pour récupérer la ressource à son nouvel emplacement. Il ne s’agit pas de bannir les 3xx, mais d’éviter les chaînes de redirections ou les redirections multiples sur une même page.
Évite toujours les redirections sur les ressources nécessaires au « Critical Rendering Path ».

• Preload Key Requests : identifie les pages HTML avec des éléments qui pourraient être gérés en « preload ».
  Quand une page est demandée, le navigateur réclame la page HTML au serveur, en analyse le contenu et envoie des requêtes distinctes pour chaque ressource référencée. Pour améliorer les performances, mieux vaut accélérer ce processus en demandant les ressources critiques en avance.
  Exemple : une police appelée dans un fichier CSS, que le navigateur ne découvrirait qu’après avoir lu la feuille de style. Avec le « preload », tu précharges une ressource que le navigateur ne prendrait en compte que plus tard, par exemple dans les critical request chains.
  Rappelle-toi que le navigateur met en cache la ressource préchargée sans exécuter de script, mais l’ayant déjà récupérée, il la servira immédiatement à la demande.
  C’est idéal pour les dépendances comme le JS, les polices et le CSS.

Cette fonction est une indication pour le navigateur qui ne bloque pas le chargement du document HTML. Pour l’implémenter, il suffit d’ajouter la balise <link> dans le <head> du HTML ou d’utiliser l’en-tête HTTP Link.

<!-- Dans la section head -->
<link rel="stylesheet" href="styles/main.css">
<link rel="preload" href="main.js" as="script">

<!-- Avec l’en-tête HTTP -->
Link: </css/style.css>; rel="preload"; as="style"

• Use Video Format for Animated Images : identifie les pages avec des GIF animés, avec le gain potentiel s’ils étaient convertis en vidéo.
• Avoid Excessive DOM size : identifie toutes les pages dont le DOM dépasse les 1 500 nœuds recommandés. Le DOM compte beaucoup, car il peut nuire aux performances de plusieurs façons :
  • le DOM contient souvent de nombreux nœuds invisibles au premier chargement ; cela augmente inutilement le volume de données servies et ralentit le chargement (performances de chargement).
  • pendant la navigation, de nombreuses interactions des utilisateurs et des scripts obligent le navigateur à recalculer la position et le style des nœuds, ce qui ralentit le rendu (performances d’exécution).
  • si le JavaScript utilise des sélecteurs généraux comme document.querySelectorAll(‘li’), il peut stocker sans le savoir des références à un très grand nombre de nœuds et saturer la mémoire des appareils (performances mémoire).
• Reduce JavaScript Execution Time : signale les pages avec un temps d’exécution JavaScript moyen ou lent. Quand une page passe beaucoup de temps à exécuter du JavaScript, les performances en pâtissent :
  • le coût réseau augmente : plus d’octets, plus de temps de téléchargement.
  • le JavaScript est analysé et compilé sur le thread principal, qui n’est plus disponible pour les interactions.
  • en occupant le thread principal, le JavaScript retarde aussi le TTI (Time to Interactive), ce qui pénalise l’UX et le web vital associé.
  • si le JavaScript contient beaucoup de références, il peut consommer énormément de mémoire et gêner la consultation de la page.

Pour améliorer l’exécution du JavaScript, le conseil général est de minifier et compresser le code, supprimer le code inutilisé et le mettre en cache.

• Serve Static Assets With An Efficient Cache Policy : renvoie toutes les pages avec des ressources non mises en cache, avec le gain potentiel. Quand un navigateur demande une ressource, le serveur peut lui indiquer combien de temps la conserver en cache. Pour chaque requête suivante, le navigateur utilise sa copie locale au lieu de la récupérer sur le réseau. Lighthouse prend en compte les polices, médias, images ou feuilles de style qui répondent en 2xx sans avoir déclaré explicitement une politique « no-cache ».

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

Cache-Control: max-age=31536000

La directive « max-age » indique au navigateur combien de temps une ressource reste en cache. Pour les ressources statiques, on conseille au moins un an.

• Minimize Main-Thread Work : identifie toutes les pages avec des temps d’exécution moyens ou lents sur le thread principal, qui pénalisent le rendu du document HTML. Le processus de rendu du navigateur transforme ton code en page web interactive. Par défaut, le thread principal gère l’essentiel du code : il analyse le HTML et construit le DOM, analyse le CSS et applique les styles, puis analyse, évalue et exécute le JavaScript.

Le thread principal traite aussi les événements utilisateur. Dès qu’il est occupé ailleurs, la page peut ne pas répondre aux interactions, d’où une mauvaise expérience. Pour l’améliorer : optimiser le JavaScript tiers, supprimer le code inutilisé, réduire et simplifier (minifier) le CSS, différer le CSS non critique et découper les payloads JavaScript.

• Ensure Text Remains Visible During Webfont Load : toutes les pages avec des polices qui peuvent clignoter ou devenir invisibles pendant leur chargement.
• Reduce Unused JavaScript : les pages avec du JavaScript chargé mais inutilisé, avec le gain potentiel.
• Avoid Serving Legacy JavaScript to Modern Browsers : les pages qui envoient des polyfills et transformations inutiles aux navigateurs modernes.
• Avoid Large Layout Shifts : les pages avec des éléments qui provoquent des décalages de mise en page, liés au CLS.
• Image Elements Do Not Have Explicit Width & Height : les images sans dimensions explicites, une cause fréquente de CLS.

Exporter les données de performance

Toutes les données de performance, les pages sources et les URL des ressources optimisables s’exportent en masse depuis le menu 1Reports›2PageSpeed.

123

1ReportsLe menu des rapports agrégés.2PageSpeedLe sous-menu des rapports de performance.3Rapports d’opportunitésOpportunities Summary, Coverage et un rapport par opportunité.