Outils

Analyseur PageSpeed Insights : comprendre les pages publiques

Demandez un rapport public et distinguez test récent et historique d’utilisateurs réels.

Appareil

Comment utiliser cet outil

  1. Saisissez l’URL publique complète avec https:// ou http://.
  2. Choisissez mobile ou ordinateur et gardez cette stratégie pour les comparaisons.
  3. Lancez l’analyse et attendez. Si le service est désactivé, utilisez l’option directe PageSpeed Insights de l’interface.
  4. Vérifiez URL renvoyée, heure de récupération et éventuel avis de cache avant de lire les valeurs.
  5. Examinez séparément laboratoire et terrain disponible, puis retenez le constat le plus pertinent.

Utilisez uniquement des pages publiques. N’envoyez aucune URL contenant mot de passe, jeton, identifiant de document privé ou autre donnée à protéger du service externe. L’analyseur ne réutilise pas votre session authentifiée pour reproduire un compte privé.

Comprendre les résultats

Lorsqu’il est activé, l’analyseur transmet l’URL à l’API PageSpeed Insights de Google via le serveur du site. Les résultats sont brièvement mis en cache et un compteur temporaire par IP limite les abus. Cela diffère des outils calculant entièrement dans le navigateur.

Lighthouse décrit une simulation susceptible de varier selon environnement et comportement de page. Le terrain éventuellement fourni décrit des expériences admissibles agrégées sur une période passée. Relancer le laboratoire ne crée pas un nouvel historique réel.

Google annonce son intention de retirer CrUX de l’API PSI et recommande les API CrUX dédiées. La disponibilité dépend donc de la réponse et de l’intégration du site. Une section absente ne signifie pas automatiquement échec des Core Web Vitals ni seulement trafic faible.

Le guide PageSpeed Insights détaille le rapport. L’analyseur résume les informations reçues ; il ne certifie ni vitesse, accessibilité, sécurité, ni admissibilité à un résultat de recherche.

Pourquoi le terrain manque-t-il ou concerne-t-il l’origine ?

La page peut manquer d’échantillons admissibles, ou les données ne pas figurer dans la réponse API. Un repli sur l’origine réunit les expériences de cette origine plutôt que de la seule URL demandée.

Vérifiez le périmètre avant d’appliquer le résultat à un modèle. Le guide terrain et laboratoire distingue couverture limitée et problème réel. Ne remplacez pas les métriques absentes par zéro.

Pourquoi la note change-t-elle entre deux analyses ?

Contenu, tiers, serveur et conditions peuvent varier. Comparez métriques, version Lighthouse, stratégie et diagnostics au lieu d’une seule couleur.

Une réponse mise en cache peut répéter l’analyse précédente jusqu’à expiration. Lisez heure et avertissements. Pour vérifier une publication, gardez des essais comparables et assurez-vous que la page retournée correspond à la version attendue.

Que faire si la requête échoue ?

Vérifiez l’accessibilité publique de l’URL et l’erreur affichée. Quota, délai dépassé, configuration désactivée et panne du fournisseur sont différents. Un test échoué n’est pas une note de performance.

Évitez les renvois répétés pendant une limitation. Avec un rapport valide, choisissez une étape précise, comme l’élément LCP ou la latence du document. La liste de contrôle suit ce travail sans considérer chaque recommandation comme également prioritaire.

Guides associés