Lisez PageSpeed Insights en trois passages : identifiez le périmètre et la métrique de terrain défaillante, examinez le test de laboratoire, puis choisissez un diagnostic qui explique le problème. L’évaluation réelle et Lighthouse répondent à des questions différentes. Un cercle vert n’annule pas une difficulté dans l’autre section.
Commencez par une URL publique représentative. Vérifiez la destination finale après redirection et choisissez mobile ou ordinateur. Conservez les conditions avant toute modification afin de comparer ensuite la même page et la même stratégie.
Vérifier d’abord la page et les conditions
Un test réussi peut décrire la mauvaise expérience. Contrôlez redirections, contenu reçu, restrictions, protection antibot et erreurs. Une page de vérification rapide ne prouve pas qu’un article charge vite.
Testez plusieurs modèles, pas seulement l’accueil. Articles, catégories, produits et recherche peuvent employer d’autres ressources. Partez d’un problème connu et vérifiez plusieurs exemples avant de valider une réparation commune.
Notez date, stratégie, URL finale, version Lighthouse et environnement. Les intitulés évoluent avec les versions. Comprenez le rôle de la section plutôt que de dépendre d’une capture ancienne.
La présentation officielle de PageSpeed Insights explique ce double regard. Le rapport lance une enquête, il ne commande pas d’appliquer indistinctement chaque suggestion.
Lire la section des utilisateurs réels en premier
CrUX décrit les visites Chrome éligibles des 28 jours précédents, avec actualisation quotidienne. Vérifiez si le panneau concerne l’URL ou toute l’origine.
Une origine combine protocole, hôte et port. Elle peut mélanger plusieurs modèles et ne démontre pas la distribution de l’article exact. Gardez cette étiquette en partageant une capture ou une métrique.
LCP concerne le chargement, INP la réactivité et CLS la stabilité. Au p75, les bons seuils sont au maximum 2,5 secondes, 200 millisecondes et 0,1. CLS n’a pas d’unité temporelle. N’additionnez ni ne moyennez des unités incompatibles.
Avec assez de données pour les trois, tous doivent être bons. PSI peut évaluer LCP et CLS si INP n’a pas assez d’observations. Si LCP ou CLS manque, l’agrégation n’est pas évaluable. INP absent ne vaut ni zéro ni un bon résultat mesuré.
Comprendre les distributions et les métriques complémentaires
Les barres représentent des proportions d’expériences bonnes, à améliorer et mauvaises. Elles ne mesurent pas le pourcentage de ressources ayant réussi un audit. Le p75 est un centile des visites, pas leur moyenne.
Une page hypothétique peut avoir un bon p75 et une queue lente visible. Cela peut justifier d’examiner pays, appareils et modèles dans votre suivi. La barre publique ne révèle pas la cause.
FCP et TTFB peuvent compléter les mesures de chargement, sans être d’autres Core Web Vitals. Un premier octet tardif peut retarder la suite ; cela ne suffit pas à prescrire un serveur plus gros. Examinez redirections, connexions, application et cache.
Conservez les unités en transférant les chiffres. Confondre secondes et millisecondes transforme une erreur de rapport en énorme régression apparente. N’ajoutez pas « ms » à CLS.
Séparer mobile et ordinateur
Le sélecteur change stratégie de laboratoire et catégorie de terrain. Le mobile réel diffère du simulé, mais les deux peuvent montrer des problèmes invisibles sur un ordinateur puissant. Ne moyennez pas les notes pour fabriquer une qualité globale.
La présentation compte : autre image principale, en-tête plus haut, menu caché ou composant différent. Si LCP varie, identifiez l’élément le plus grand dans chaque version avant de choisir une intervention sur images ou serveur.
Testez les parcours importants sur chaque format. Un site qui tient dans l’écran peut avoir un menu lent ou une publicité instable. Adaptation du CSS et réactivité mesurée par INP ne sont pas synonymes.
L’introduction aux Core Web Vitals relie ces différences à l’usage. Gardez des références séparées pour ne pas masquer une régression par l’autre amélioration.
Interpréter Lighthouse comme un résumé de laboratoire
La section diagnostique analyse l’URL dans des conditions configurées. Le score va de 0 à 100 : bon dès 90, à améliorer entre 50 et 89, mauvais sous 50. Ces catégories ne sont pas les seuils des métriques de terrain.
La note combine des scores pondérés. Les recommandations expliquent des causes possibles ; corriger une alerte n’accorde pas un nombre fixe de points. Comparez versions, conditions et temps individuels.
Un petit changement de temps peut déplacer la note alors qu’une amélioration utile laisse le même entier arrondi. Examinez la métrique concernée sur plusieurs essais et vérifiez que la page fonctionne.
Accessibilité, Bonnes pratiques et SEO couvrent d’autres vérifications limitées. Une bonne note SEO ne promet pas de classement, et l’automatisation ne remplace pas un audit complet d’accessibilité. Expliquez ces limites aux responsables non techniques.
Relier chaque mesure à une enquête
La navigation mesure chargement et CLS observé pendant le test. Elle peut manquer les mouvements tardifs et ne fournit pas la distribution INP réelle. Les interactions nécessitent un scénario adapté.
Cette table distingue les usages sans rendre les mesures interchangeables.
| Mesure | Ce qu’elle aide à examiner | Ce qu’elle ne prouve pas |
|---|---|---|
| LCP | Livraison et rendu du plus grand contenu | Réactivité des actions ultérieures |
| CLS | Mouvement inattendu observé | Stabilité après la fin du test |
| FCP | Apparition du premier contenu | Disponibilité du contenu principal |
| TBT | Blocage du thread principal au chargement | Valeur INP de terrain |
| Speed Index | Progression de l’affichage | Réussite indépendante des Core Web Vitals |
Avec un TBT élevé, examinez tâches longues et scripts. Avec un INP mauvais, reproduisez saisie, menus et options. TBT peut orienter, pas remplacer l’étiquette INP.
Si les CLS diffèrent, prolongez l’enregistrement et testez le contenu tardif. Le guide terrain et laboratoire explique ces écarts avant de déclarer une source incorrecte.
Prioriser les diagnostics selon leur effet explicable
Ouvrez les insights liés à la métrique problématique. Malgré les changements d’intitulés, les questions restent : qu’est-ce qui retarde découverte, transfert ou rendu, bloque le thread ou modifie la disposition ?
Pour LCP, suivez l’élément dans la cascade réseau. L’image peut être découverte tard, attendre une priorité ou finir son téléchargement avant de pouvoir s’afficher. Corrigez la phase dominante plutôt que seulement la taille.
Pour les ressources bloquant le rendu, distinguez ce qui est nécessaire au départ. Tout reporter peut afficher du contenu sans styles ou casser les dépendances. Le guide des ressources bloquantes explique le choix.
Les économies estimées viennent du modèle de test, pas d’une garantie pour chaque visiteur. Les recommandations peuvent se chevaucher : ne les additionnez pas en une promesse globale. Appliquez un changement justifiable, puis mesurez son effet.
Transformer le constat en tâche reproductible
Un ticket utile nomme page, appareil, métrique, preuve et composant proposé. Ajoutez la requête ou le script concerné plutôt que le seul rapport avec « passez au vert ». Une vérification fonctionnelle évite de réussir en supprimant la fonction utile.
Un ticket image peut demander une découverte dans le HTML initial et le contrôle de la variante responsive. L’acceptation comprendrait LCP et affichage correct à plusieurs largeurs. C’est un exemple de méthode, pas un diagnostic de votre site.
Priorisez les éléments communs si la preuve le justifie. Un script d’en-tête partagé peut compter davantage qu’un décor isolé, mais des couleurs similaires ne prouvent pas une cause commune. Prévoyez un retour arrière pour les changements de rendu ou d’application.
Traiter l’absence de données selon sa cause
Une URL nouvelle, peu observée ou non publiquement découvrable peut manquer de terrain. L’origine fournit du contexte sans remplacer ce dossier absent. Une application privée requiert une autre stratégie.
Une intégration peut aussi manquer de terrain à cause d’une évolution d’API, de configuration ou d’une erreur. Distinguez « aucun dossier CrUX », « requête échouée » et « intégration sans terrain ». Ces états ne doivent pas recevoir le même échec rouge.
Continuez les tests adaptés et envisagez un RUM respectueux de la vie privée. Ne créez pas un centile à partir d’un seul essai et ne transformez pas l’absence en réussite.
Utiliser l’API avec stratégie et gestion d’erreurs
L’API PSI v5 fournit une analyse Lighthouse programmable. Cette commande demande la catégorie performance d’une URL publique illustrative et enregistre le JSON. Elle nécessite curl ; accès, quotas et configuration restent applicables.
curl --fail-with-body --get \
'https://www.googleapis.com/pagespeedonline/v5/runPagespeed' \
--data-urlencode 'url=https://example.com/' \
--data-urlencode 'strategy=mobile' \
--data-urlencode 'category=performance' \
--output pagespeed-mobile.jsonPour l’automatisation, configurez clé et quotas selon Google. N’exposez pas de clé sans restrictions dans le navigateur. Vérifiez HTTP et erreurs JSON avant lighthouseResult et conservez heure, URL finale, version et paramètres.
Google annonce son intention de retirer CrUX de cette API et recommande CrUX API ou CrUX History API. Ne supposez pas la présence permanente de loadingExperience et originLoadingExperience. Séparez récupérations de laboratoire et de terrain, avec traitement explicite des champs absents.
L’API ne donne aucune autorisation pour analyser des URLs privées. Évitez jetons et données personnelles dans les adresses. Un service public doit valider les destinations et limiter les abus côté serveur.
Refaire les tests après une modification utile
Répétez des essais comparables après un changement ciblé et conservez les métriques individuelles. Testez également la fonction affectée. Répéter sans modification montre surtout de la variabilité et ne crée pas de visites pour le terrain.
Consultez vos mesures récentes puis la tendance publique pendant le renouvellement des 28 jours. Notez versions et changements d’audience. La cohérence entre scénarios représentatifs vaut mieux qu’un essai exceptionnellement favorable.
Ouvrez l’analyseur PageSpeed lorsqu’il est activé, puis les guides de vitesse des pages. Terminez avec une action mesurable, un responsable et une condition de nouveau test, pas une liste d’avertissements inexpliqués.
