Lire un résultat Page Speed
Un résultat Page Speed montre plus que des scores. Sous les jauges de score, des panneaux expliquent pourquoi la page a été rapide ou lente : quel élément était le Largest Contentful Paint, ce qui s'est déplacé, quels scripts ont occupé le CPU et dans quel ordre chaque requête s'est chargée. Ce guide parcourt chaque panneau et vous dit quoi faire de ce que vous voyez.
Un panneau n'apparaît que si l'exécution a des données pour lui. Par exemple, une exécution sans données de décalage de mise en page n'a pas de carte Éléments qui se sont déplacés.
Relecture du chargement de la page
À côté des jauges de score, la dernière capture de la page se trouve dans un petit lecteur. Cliquez dessus pour rejouer le chargement de la page et voir quand le contenu apparaît. L'icône d'agrandissement (Voir la capture complète) ouvre la dernière capture en taille réelle.
Servez-vous-en comme d'une vérification rapide avant de lire les chiffres. Si la page reste blanche longtemps, ou si une bannière arrive tard et pousse le contenu vers le bas, vous le voyez ici.
Diagnostic de performance
La section Diagnostic de performance lit la trace Lighthouse de cette exécution et montre ce qui l'a ralentie. Elle compte jusqu'à quatre cartes.
Élément Largest Contentful Paint
Cette carte nomme l'élément qui a été le Largest Contentful Paint (LCP) et montre son extrait HTML. Elle recadre aussi la capture de la page autour de l'élément et dessine un cadre dessus. La valeur à côté du titre est le temps du LCP.
Sous Décomposition du LCP, le temps du LCP est réparti en quatre phases, chacune avec son temps et sa part :
| Phase | Ce qu'elle couvre | Si elle prend la plus grande part |
|---|---|---|
| Temps jusqu'au premier octet | Jusqu'à l'arrivée du premier octet du HTML | Accélérez le serveur : cache, CDN, moins de redirections |
| Délai avant le chargement de la ressource | De ce premier octet jusqu'au moment où le navigateur commence à charger la ressource du LCP, comme l'image principale | Rendez la ressource visible tôt : mettez-la dans le HTML, préchargez-la, pas de chargement différé |
| Temps de chargement de la ressource | Le téléchargement de la ressource du LCP | Allégez-la : compressez l'image, utilisez un format moderne, servez la bonne taille |
| Délai d'affichage de l'élément | De la ressource prête jusqu'à l'affichage de l'élément | Réduisez le CSS et le JavaScript qui bloquent le rendu et les longues tâches du thread principal |
Un élément texte n'a pas de ressource à télécharger, donc l'essentiel de son temps se trouve dans la première et la dernière phase. Plus d'informations sur la métrique dans Largest Contentful Paint (LCP).
Éléments qui se sont déplacés
Les cinq éléments qui ont le plus contribué au Cumulative Layout Shift (CLS), le plus important en premier. Chaque ligne montre l'élément, son sélecteur CSS et son score de décalage. Le score suit les seuils des Core Web Vitals : sous 0,1 c'est bon, à partir de 0,1 c'est à améliorer, à partir de 0,25 c'est mauvais. Si rien n'a bougé, la carte indique Aucun décalage de mise en page enregistré.
Corrections habituelles : donnez aux images, vidéos, publicités et intégrations une largeur et une hauteur ou un espace réservé. N'insérez pas de bannières ou d'autre contenu au-dessus de ce qui est déjà à l'écran.
Temps CPU par script
Les cinq scripts qui ont utilisé le plus de temps CPU sur le thread principal, avec leur hôte et une barre pour les comparer. Autre (non attribuable) correspond au travail que Lighthouse ne peut pas attribuer à un seul script.
Le travail du thread principal fait monter le Total Blocking Time. Si un hôte tiers est en tête de liste, vérifiez si cette page a vraiment besoin de ce script, ou chargez-le plus tard. Si c'est votre propre bundle, découpez-le et différez le code dont le premier affichage n'a pas besoin.
Poids de la page
La taille totale transférée et le nombre de requêtes. En dessous, une barre et une liste répartissent le poids par type de ressource (Document, Script, CSS, Image, Police, Média, Autre), chacun avec sa taille, ses requêtes et sa part. La dernière ligne indique ce qui vient de tiers, par exemple "Tiers : 1.2 MB en 40 requêtes (35 % du poids)".
Les images et les scripts représentent généralement la plus grande part. Pour être alerté quand la page grossit, définissez un budget sur Page Weight (KB) ou Requests. Voir Budgets de performance.
Cascade des requêtes
La Cascade des requêtes liste chaque requête de la page, dans l'ordre où elles ont démarré. La ligne sous le titre donne le nombre de requêtes et la taille transférée.
Les temps proviennent du chargement réel, sans limitation. Ils peuvent être plus courts que les métriques de laboratoire limitées des jauges. Utilisez la cascade pour l'ordre des requêtes et ce qui a attendu quoi, pas pour les temps absolus.
Ce que vous voyez :
- Pellicule : des captures de la page pendant le chargement, sur la même échelle de temps que la cascade. La première image au moment du First Contentful Paint ou après porte l'étiquette FCP, la première au moment du Largest Contentful Paint ou après porte l'étiquette LCP. Survolez une image pour tracer son instant en ligne sur la cascade.
- Filtre par type : une puce Tout et une par type de ressource présent sur la page, avec un compteur. Cliquez sur une puce pour n'afficher que ce type.
- Repères : des lignes verticales pour First Contentful Paint, Largest Contentful Paint et Événement load. La légende donne leurs temps.
- Lignes : chaque requête montre le nom du fichier, l'hôte, la priorité du navigateur (de La plus haute à La plus basse), le code de statut s'il n'est pas 200 et la taille transférée. La partie claire de la barre est l'attente avant le début de la requête. La partie pleine est la requête elle-même. Survolez la barre pour voir son début et sa fin.
- Bloque le rendu : la requête a retardé le premier affichage, par exemple une feuille de style ou un script synchrone dans le head.
- Préchargé : la page a demandé la requête tôt avec un lien
rel="preload". - Non chargé : la requête ne s'est jamais terminée. Elle figurait dans la liste Bloquer des requêtes du test ou a échoué sur le réseau.
La liste commence par les 30 premières requêtes. Cliquez sur Afficher les N requêtes sous la liste pour voir le reste, et sur Afficher moins pour la replier.
Comment l'utiliser :
- Regardez ce qui se charge avant le repère FCP. Chaque requête Bloque le rendu à cet endroit retarde le premier affichage. Intégrez le CSS critique dans la page et ajoutez
deferouasyncaux scripts qui n'ont pas besoin de bloquer. - Trouvez la ressource du LCP, souvent une image. Si elle démarre tard, après une chaîne de CSS et de scripts, préchargez-la. Quand elle porte l'étiquette Préchargé, vérifiez qu'elle démarre maintenant près du début.
- Filtrez sur Script pour voir combien de scripts se chargent et depuis quels hôtes.
- Une longue période sans nouvelle requête signifie souvent que le thread principal est occupé. Comparez avec Temps CPU par script.
Temps de réponse du serveur (TTFB)
Les cartes de métriques du résultat incluent Temps de réponse du serveur (TTFB) : le temps mis par le serveur pour commencer à envoyer le document HTML principal. Comme les autres cartes, elle montre la valeur Dernier et la Médiane. Une bonne valeur est de 0,8 seconde ou moins. Au-delà de 1,8 seconde, elle est mauvaise. Les graphiques d'historique ont aussi un graphique Temps de réponse du serveur (TTFB), qui inclut les anciennes exécutions.
Un TTFB lent retarde toutes les autres métriques, car rien ne peut démarrer avant l'arrivée du HTML. Regardez le cache côté serveur, les requêtes lentes à la base de données, un CDN devant le site et les redirections.
Dans le rapport PDF
Le rapport imprimable inclut le Diagnostic de performance et la Cascade des requêtes. Dans le PDF, la cascade liste toutes les requêtes, pas seulement les 30 premières, et laisse de côté les puces de filtre et les boutons. Voir Rapports PDF à votre marque.