PageSpeed Insights (PSI) génère des rapports sur l'expérience utilisateur d'une page à la fois sur mobile et sur ordinateur. d'appareils mobiles, et suggère des améliorations possibles.
L'outil PSI fournit à la fois des données expérimentales et des données réelles sur une page. Ces données sont utiles pour le débogage car elles sont collectées dans un environnement contrôlé. Cependant, il se peut qu'il ne soit pas détecter les goulots d'étranglement réels. Les données de terrain sont utiles pour capturer des utilisateurs réels et réels mais avec un ensemble plus limité de métriques. Voir comment aborder À propos de Speed Tools pour en savoir plus sur ces deux types de données.
Données sur l'expérience utilisateur réelle
Les données d'expérience utilisateur réelle dans PSI sont alimentées par l'expérience utilisateur Chrome d'analyse (CrUX). L'outil PSI rapporte les performances des utilisateurs réels Première Contentful Paint (FCP), Interaction to Next Paint (INP), Largest Contentful Paint (LCP) et Cumulative Layout Shift (CLS) au cours de la précédente période de collecte de 28 jours. PSI rapporte aussi pour la métrique expérimentale Time to First Byte (TTFB).
Pour afficher les données d'expérience utilisateur pour une page donnée, la quantité de données doit être suffisante. à inclure dans le jeu de données CrUX. Il est possible qu'une page ne contienne pas suffisamment de données ont été récemment publiés ou ne disposent que d'un nombre insuffisant d'échantillons provenant d'utilisateurs réels. Lorsque cela se produit, le PSI chute à la granularité au niveau de l'origine, qui englobe toutes les expériences utilisateur sur toutes les pages du sur votre site Web. Parfois, l'origine peut aussi comporter des données insuffisantes, auquel cas PSI sera ne peut afficher aucune donnée d’expérience utilisateur réelle.
Évaluer la qualité des expériences
PSI classe la qualité de l'expérience utilisateur en trois catégories: bonne, amélioration nécessaire, ou "Médiocre". L'équipe PSI définit les seuils suivants conformément aux Initiative Web Vitals:
Bonne | Amélioration nécessaire | Médiocre | |
---|---|---|---|
FCP | [0, 1800ms] | (1 800 ms, 3 000 ms) | plus de 3 000 ms |
LCP | [0, 2500ms] | (2 500 ms, 4 000 ms) | plus de 4 000 ms |
CLS | [0, 0,1] | (0,1, 0,25] | supérieure à 0,25 |
INP | [0, 200ms] | (200 ms, 500 ms) | plus de 500 ms |
TTFB (expérimental) | [0, 800ms] | (800ms, 1800ms] | plus de 1 800 ms |
Répartition et valeurs des métriques sélectionnées
PSI présente une distribution de ces métriques afin que les développeurs puissent comprendre l'éventail des pour cette page ou origine. Cette distribution est divisée en trois catégories: "Bon", "Amélioration nécessaire" et "Médiocre", représentés par des barres vertes, orange et rouges. Par exemple, 11% dans la barre orange du LCP indique que 11% de toutes les valeurs de LCP observées se situent entre 2 500 ms et 4 000 ms.
![Capture d'écran de la répartition des expériences LCP des utilisateurs réels](https://developers.google.cn/static/speed/docs/insights/images/v5/metric_distribution.jpeg?authuser=0000&hl=fr)
Au-dessus des barres de distribution, l'outil PSI indique le 75e centile pour toutes les métriques. Le 75 centile est sélectionné afin que les développeurs puissent identifier les expériences utilisateur frustrantes sur leur site. Ces valeurs de métriques de champ sont classées en tant que de bonnes/d'améliorations/d'améliorations médiocres en appliquant les mêmes seuils que ceux indiqués ci-dessus.
Core Web Vitals
Les Core Web Vitals sont un ensemble commun de signaux de performances essentiels pour toutes les expériences Web. Les métriques Core Web Vitals sont INP, LCP et CLS. Elles peuvent être au niveau de la page ou de l'origine. Pour les agrégations comportant suffisamment de données dans l'ensemble trois métriques, l'agrégation réussit l'évaluation Core Web Vitals si les 75e centiles des trois métriques sont bonnes. Sinon, l'agrégation échouera à l'évaluation. Si le l'agrégation ne dispose pas de données suffisantes pour INP, alors l'évaluation réussira si la 75e centiles du LCP et du CLS sont satisfaisants. Si les données LCP ou CLS sont insuffisantes, la page ou l'agrégation au niveau de l'origine ne peut pas être évaluée.
Différences entre les données de terrain dans PSI et CrUX
Différence entre les données de champ dans PSI et Ensemble de données CrUX sur BigQuery, les données de PSI sont mises à jour quotidiennement. tandis que l'ensemble de données BigQuery est mis à jour tous les mois et limité aux données au niveau de l'origine. Les deux sources de données représentent des périodes de 28 jours consécutifs.
Diagnostics de l'atelier
L'outil PSI utilise Lighthouse pour analyser l'URL donnée dans une simulation pour les catégories "Performances", "Accessibilité", "Bonnes pratiques" et "SEO".
Score
En haut de la section se trouvent les scores de chaque catégorie, déterminés en exécutant Lighthouse pour collecter et analyser les informations de diagnostic de la page. Un score de 90 ou plus est considéré comme bien. Entre 50 et 89 correspond à un score qui doit être amélioré, tandis qu'un score inférieur à 50 est considéré comme faible.
Métriques
La catégorie "Performances" inclut également les performances de la page en fonction de différentes métriques, dont les suivantes: First Contentful Paint, Largest Contentful Paint, Indice de vitesse, Cumulative Layout Shift, Délai avant interactivité, et Total Blocking Time.
Chaque métrique est notée et libellée par une icône:
- Un cercle vert indique "Bon".
- L'amélioration est nécessaire, avec un carré d'information en orange.
- L'état "Médiocre" est représenté par un triangle d'avertissement rouge.
Audits
Dans chaque catégorie se trouvent des audits qui fournissent des informations sur la façon d'améliorer l'expérience utilisateur de la page expérience. Consultez la documentation de Lighthouse la répartition des audits de chaque catégorie.
Questions fréquentes
Quelles sont les conditions d'appareil et de réseau utilisées par Lighthouse pour simuler le chargement d'une page ?
Actuellement, Lighthouse simule les conditions de chargement de page sur un appareil de milieu de gamme (Moto G4). sur un réseau mobile pour mobile et émulé-desktop avec une connexion filaire pour les ordinateurs de bureau. PageSpeed s'exécute également pouvant varier en fonction des conditions du réseau, vous pouvez vérifier l'emplacement sur lequel était d'examiner le bloc d'environnement du rapport Lighthouse:
![Capture d'écran de l'info-bulle d'informations sur la limitation.](https://developers.google.cn/static/speed/docs/insights/images/v5/lh_network_throttling.jpeg?authuser=0000&hl=fr)
Remarque: Page Speed indique qu'il s'exécute dans l'un des pays suivants: Amérique du Nord, Europe ou Asie.
Pourquoi les données de terrain et les données de laboratoire se contredisent-elles parfois ?
Les données de champ sont un rapport historique sur les performances d'une URL spécifique. Elles représentent des données de performances anonymisées provenant d'utilisateurs réels sur divers appareils et réseaux et conditions d'exploitation. Ces données de l'atelier sont basées sur la simulation du chargement d'une page sur un seul appareil et les erreurs l'ensemble des conditions du réseau. Par conséquent, les valeurs peuvent différer. Consultez l'article Pourquoi les données expérimentales et les données réelles peuvent-elles être différentes ? (et la procédure à suivre).
Pourquoi le 75e centile est-il choisi pour toutes les métriques ?
Notre objectif est de nous assurer que les pages fonctionnent bien pour la majorité des utilisateurs. En se concentrant sur les 75 de centiles pour nos métriques, ce qui permet de garantir que les pages offrent une bonne expérience utilisateur dans les conditions les plus difficiles liées aux appareils et aux réseaux. Consultez Définir les seuils des métriques Core Web Vitals. pour en savoir plus.
Qu'est-ce qu'un bon score pour les données de test ?
Tout score vert (plus de 90) est considéré comme satisfaisant. Notez toutefois que disposer de bonnes données de laboratoire ne signifient nécessairement que de vraies expériences utilisateur seront également bonnes.
Pourquoi le score de performance varie-t-il d'une exécution à l'autre ? Je n'ai rien modifié sur ma page !
La variabilité des mesures des performances est introduite via un de chaînes présentant différents niveaux d'impact. Plusieurs sources de métriques courantes la variabilité sont la disponibilité du réseau local, la disponibilité du matériel client et la disponibilité des ressources client. les conflits.
Pourquoi les données CrUX des utilisateurs réels ne sont-elles pas disponibles pour une URL ou une origine ?
Le rapport d'expérience utilisateur Chrome regroupe des données réelles sur la vitesse utilisateurs l'ayant activée et nécessite qu'une URL soit publique (explorable et indexable) et disposent d'un nombre suffisant d'échantillons distincts qui offrent une vue représentative et anonyme. des performances de l'URL ou de l'origine.
D'autres questions ?
Si vous avez une question précise concernant l'utilisation de PageSpeed Insights, posez votre question en anglais sur Stack Overflow.
Si vous avez des commentaires ou des questions d'ordre général sur PageSpeed Insights, ou si vous voulez démarrer un discussion générale, démarrez un fil de discussion dans la liste de diffusion.
Si vous avez des questions d'ordre général sur les métriques Web Vitals, créez un fil de discussion dans le groupe de discussion web-vitals-feedback.
Commentaires
Cette page vous a-t-elle été utile ?