PageSpeed Insights expliqué : ce que signifie chaque score et comment l'améliorer
PageSpeed Insights expliqué
PageSpeed Insights expliqué : scores, métriques et correctifs | We.Inc
Ce que signifie chaque chiffre de PageSpeed Insights, la différence entre données terrain et données de laboratoire, les seuils LCP, INP, CLS, FCP et TTFB, les pondérations du score et le code qui corrige les résultats en rouge.
PageSpeed Insights affiche deux rapports. Celui du haut contient les données terrain de vrais visiteurs Chrome sur les 28 derniers jours, évaluées au 75e centile. Celui du bas est un test de laboratoire Lighthouse noté de 0 à 100 : 90 ou plus est bon, de 50 à 89 doit être amélioré, sous 50 est mauvais. Corrigez d'abord les métriques terrain.
Seuils des métriques terrain utilisés par PageSpeed Insights
Métrique
Bon
À améliorer
Mauvais
LCP (Largest Contentful Paint)
2.5 s ou moins
de 2.5 à 4 s
plus de 4 s
INP (Interaction to Next Paint)
200 ms ou moins
de 200 à 500 ms
plus de 500 ms
CLS (Cumulative Layout Shift)
0.1 ou moins
de 0.1 à 0.25
plus de 0.25
FCP (First Contentful Paint)
1.8 s ou moins
de 1.8 à 3 s
plus de 3 s
TTFB (expérimental)
0.8 s ou moins
de 0.8 à 1.8 s
plus de 1.8 s
La plupart des gens fixent le grand score circulaire, mais ce chiffre provient d'une seule visite simulée sur un téléphone bridé. Ce guide sépare les deux moitiés du rapport, vous permet d'évaluer vos propres chiffres par rapport aux seuils officiels et associe chaque métrique en rouge à la modification qui la fait généralement bouger.
Analysez votre URL sur pagespeed.web.dev et regardez d'abord le bloc des données terrain. S'il indique qu'il n'y a pas assez de données, seul le test de laboratoire est disponible.
Saisissez vos valeurs LCP, INP, CLS, FCP et TTFB dans l'évaluateur ci-dessous pour voir dans quelle tranche tombe chacune.
Ouvrez la section des correctifs pour la pire métrique et appliquez la modification de code correspondante.
Attendez les nouvelles données terrain. Le rapport sur les utilisateurs réels couvre 28 jours glissants, donc les améliorations apparaissent progressivement, pas dès le lendemain matin.
Le test de laboratoire mobile s'exécute sur un téléphone milieu de gamme émulé avec un réseau lent, il est donc normal que le score mobile soit inférieur à celui du bureau.
Les scores de laboratoire varient de quelques points d'une exécution à l'autre. Lancez le test trois fois et retenez le résultat médian avant de conclure à un changement.
Le test de laboratoire ne peut pas mesurer l'INP car personne ne clique. Le Total Blocking Time le remplace, donc un TBT élevé annonce généralement un mauvais INP.
Les balises tierces comme les widgets de discussion, les heatmaps et les scripts publicitaires coûtent souvent plus cher que votre propre code. Consultez la liste des requêtes tierces avant de réécrire votre application.
Questions fréquentes
Pourquoi mes données terrain et mon score de laboratoire sont-ils si différents ?
Ils ne mesurent pas la même chose. Les données terrain reflètent ce qu'ont vécu de vrais utilisateurs Chrome, sur leurs propres appareils et réseaux, pendant 28 jours. Le score de laboratoire correspond à un seul chargement simulé avec un bridage fixe. Une page peut obtenir 60 en laboratoire et réussir quand même les Core Web Vitals sur le terrain, ou l'inverse.
Le score Lighthouse influence-t-il le classement Google ?
Google décrit les Core Web Vitals comme des mesures de l'expérience utilisateur réelle, en phase avec ce que récompensent ses systèmes de classement principaux. Ses consignes pour la recherche ne citent pas le score de laboratoire de 0 à 100 comme critère de classement : considérez donc ce score comme un outil de diagnostic pour trouver les problèmes.
Qu'est-ce que le TTFB et quelle est une bonne valeur ?
Le Time to First Byte est le temps pendant lequel le navigateur attend avant de recevoir le premier octet du HTML, redirections, DNS, établissement de la connexion et traitement serveur compris. PageSpeed Insights considère 800 ms ou moins comme bon. Mettre le HTML en cache en périphérie d'un CDN est la solution la plus courante.
Comment le score de performance Lighthouse est-il calculé ?
Depuis Lighthouse 10, c'est une moyenne pondérée de cinq métriques de laboratoire : Total Blocking Time 30 pour cent, LCP 25 pour cent, CLS 25 pour cent, FCP 10 pour cent et Speed Index 10 pour cent. Chaque métrique est d'abord convertie en un sous-score de 0 à 100 selon une courbe.
Pourquoi est-il indiqué qu'il n'y a pas de données terrain pour mon site ?
Le Chrome User Experience Report ne publie des données que pour les pages et origines ayant assez de visites éligibles. Les sites récents ou peu fréquentés n'en ont souvent aucune : appuyez-vous alors sur le test de laboratoire et sur votre propre suivi jusqu'à ce que le trafic augmente.
Lisez le rapport de haut en bas
Le premier bloc indique si les vrais visiteurs ont eu une bonne expérience. Il affiche la valeur au 75e centile pour chaque métrique, ce qui signifie que trois visites sur quatre ont été au moins aussi rapides. L'objectif est de réussir les trois Core Web Vitals (LCP, INP et CLS).
Le second bloc correspond à une seule exécution de Lighthouse. Ses diagnostics et opportunités vous permettent de comprendre pourquoi une métrique terrain est lente, car la trace de laboratoire liste les fichiers, images et scripts réellement en cause.
Un exemple concret avant et après
Prenons la page d'accueil typique d'une petite entreprise, avec une photo d'en-tête pleine largeur chargée en différé, une police web sans stratégie de repli et trois balises marketing dans le head. Dans cet exemple, l'image LCP ne commence à se télécharger qu'une fois le script terminé, et le LCP tombe donc dans la tranche mauvaise.
Retirer loading=lazy de l'image d'en-tête, ajouter fetchpriority=high, servir la photo en AVIF ou WebP à la taille affichée et charger les balises une fois la page interactive permet d'agir sur chaque sous-partie du LCP. Ce sont les modifications présentées dans le code ci-dessous ; vos propres chiffres dépendront de votre page.
Là où chaque métrique dérape en général
Le LCP se décompose en quatre parties : temps jusqu'au premier octet, délai avant chargement de la ressource, durée de chargement de la ressource et délai de rendu de l'élément. Identifiez d'abord la plus grosse partie, puis corrigez-la.
L'INP dépend des longues tâches JavaScript qui s'exécutent quand quelqu'un touche l'écran ou tape au clavier. Le CLS vient des éléments qui changent de taille après le premier affichage : images sans dimensions, bannières tardives et polices qui se remplacent par une autre de largeur différente.
Comment le score de laboratoire est pondéré
Depuis Lighthouse 10, cinq métriques de laboratoire sont combinées. Le Total Blocking Time pèse le plus lourd, donc un JavaScript lourd pénalise le score plus que tout le reste.
Pondérations du score de performance Lighthouse
Métrique de laboratoire
Poids
Métrique terrain associée
Total Blocking Time
INP
Largest Contentful Paint
LCP
Cumulative Layout Shift
CLS
First Contentful Paint
FCP
Speed Index
Aucune directement
Audits courants et correctif de chacun
Ce que vous dit un audit en rouge
Audit ou symptôme
Pourquoi il est en rouge
Correctif habituel
L'image Largest Contentful Paint a été chargée en différé
Le navigateur attend la mise en page avant de récupérer l'image d'en-tête
Retirer loading=lazy de l'image d'en-tête et ajouter fetchpriority=high
Éliminez les ressources qui bloquent le rendu
Le CSS ou les scripts synchrones du head retardent le premier affichage
Intégrer le CSS critique, différer les scripts
Dimensionnez correctement les images
Les images sont plus grandes que leur taille d'affichage
Utiliser srcset et sizes, exporter à la largeur d'affichage
Diffusez des images aux formats modernes
Du JPEG ou PNG là où l'AVIF ou le WebP serait plus léger
Convertir et servir avec picture ou un CDN d'images
Réduisez le JavaScript inutilisé
Du code livré pour des fonctionnalités absentes de cette page
Découper les bundles par route, supprimer les bibliothèques inutilisées
Réduisez l'impact du code tiers
Les balises bloquent le thread principal
Charger les balises après interaction ou au repos
Les éléments d'image n'ont pas de largeur ni de hauteur explicites
L'espace n'est pas réservé, donc le contenu saute
Définir width et height ou aspect-ratio
Assurez-vous que le texte reste visible pendant le chargement des polices web
Le texte est masqué pendant le téléchargement de la police
Utiliser font-display: swap et précharger la police principale
Le temps de réponse initial du serveur était long
TTFB lent dû à un HTML non mis en cache
Mettre le HTML en cache en périphérie, réduire les redirections
Extraits de correctifs
Image d'en-tête chargée en premier
Pas de chargement différé sur l'élément LCP probable, une priorité de récupération élevée, des formats modernes et de vraies dimensions pour que rien ne bouge.
Police qui ne masque pas le texte
Préchargez le seul fichier de police utilisé au-dessus de la ligne de flottaison et laissez le texte s'afficher dans une police de repli en attendant.
Balise tierce chargée une fois la page stabilisée
Injecte un script marketing quand le navigateur est inactif, pour qu'il ne concurrence ni le premier rendu ni le premier toucher.
Réserver l'espace pour le contenu tardif
Un contenu intégré ou un emplacement publicitaire au ratio fixe empêche le contenu situé dessous de sauter lors du chargement.
Liste de contrôle de la vitesse
Suivez ces étapes dans l'ordre
Étape
Vérification
Données terrain : lesquelles parmi LCP, INP et CLS échouent au 75e centile ?
Élément LCP : est-ce une image, et est-elle chargée en différé ou découverte tardivement ?
TTFB : le HTML est-il en cache, et y a-t-il des redirections avant lui ?
JavaScript : quel est le Total Blocking Time et quels scripts en sont la cause ?
Mise en page : les images, contenus intégrés et bannières ont-ils un espace réservé ?
Polices : font-display est-il défini et le fichier principal est-il préchargé ?
Bon
À améliorer
Mauvais
Évaluez vos chiffres
Saisissez les valeurs de votre rapport pour savoir si chacune est bonne, à améliorer ou mauvaise.