Un guide détaillé pour mesurer les éléments vitaux du Web

Google a annoncé qu'à partir du 1er mai, il commencerait à considérer "Expérience de page" dans le cadre du classement de recherche tel que mesuré par un ensemble de métriques appelé Core Web Vitals. Cette date approche rapidement et je suis sûr que nous sommes nombreux à être invités à nous assurer que nous passons nos Core Web Vitals, mais comment savoir si c'est le cas?

Répondre à cette question est en fait plus difficile que vous ne le pensez et alors que de nombreux outils exposent désormais ces éléments essentiels du Web, il existe de nombreux concepts et subtilités importants à comprendre. même les outils Google comme PageSpeed ​​Insights et le rapport Core Web Vitals dans Google Search Console semblent donner des informations confuses.

Pourquoi et comment pouvez-vous être sûr que vos correctifs vraiment travaillé? Comment pouvez-vous obtenir une image précise des Core Web Vitals de votre site? Dans cet article, je vais essayer d'expliquer un peu plus ce qui se passe ici et d'expliquer certaines des nuances et des malentendus de ces outils.

Que sont les principaux Web Vitals?

The Core Les Web Vitals sont un ensemble de trois mesures conçues pour mesurer l'expérience «de base» de savoir si un site Web est rapide ou lent pour les utilisateurs, et donne ainsi une bonne expérience.

Les pages Web devront être dans les mesures vertes pour les trois Core Web Vitals pour bénéficier de toute amélioration de classement.

1. Largest Contentful Paint (LCP)

Cette métrique est probablement la plus facile à comprendre – elle mesure la rapidité avec laquelle vous obtenez le plus gros élément dessiné sur la page – qui est probablement le contenu qui intéresse l'utilisateur. Cela pourrait être un image de bannière, un morceau de texte, ou autre. Le fait qu’il s’agisse de l’élément de contenu le plus important de la page est un bon indicateur du fait qu’il s’agit de l’élément le plus important. LCP est relativement nouveau, et nous avions l'habitude de mesurer le First Contentful Paint (FCP), nommé de manière similaire, mais LCP a été considéré comme une meilleure mesure pour le moment où le contenu que le visiteur souhaite probablement voir est dessiné.

LCP est censé mesurer performances de chargement et est un bon proxy pour toutes les anciennes métriques que nous dans la communauté des performances utilisions (c'est-à-dire Time to First Byte (TTFB), DOM Content Loaded, Start Render, Speed ​​Index) – mais d'après l'expérience de l'utilisateur. Il ne couvre pas toutes les informations couvertes par ces métriques, mais est une métrique simple et unique qui tente de donner une bonne indication du chargement de la page.

2. Premier délai d'entrée (FID)

Cette deuxième métrique mesure le temps entre le moment où l'utilisateur interagit avec une page, en cliquant sur un lien ou un bouton par exemple, et le moment où le navigateur traite ce clic. Il permet de mesurer l’interactivité d’une page . Si tout le contenu est chargé, mais que la page ne répond pas, c'est une expérience frustrante pour l'utilisateur.

Un point important est que cette métrique ne peut pas être simulée car elle dépend vraiment du moment où un utilisateur clique ou interagit d'une autre manière avec un page, puis combien de temps cela prend pour être mis en œuvre. Le temps total de blocage (TBT) est un bon proxy pour le FID lorsque vous utilisez un outil de test sans aucune interaction directe de l'utilisateur, mais gardez également un œil sur le temps d'interactivité (TTI) lorsque vous regardez le FID.

3. Cumulative Layout Shift (CLS)

Une métrique très très intéressante, contrairement à d'autres métriques qui ont précédé pour un certain nombre de raisons. Il est conçu pour mesurer la stabilité visuelle de la page – essentiellement combien elle saute lorsque de nouveaux emplacements de contenu se mettent en place. Je suis sûr que nous avons tous cliqué sur un article, commencé à lire, puis fait sauter le texte lorsque des images, des publicités et d'autres contenus sont chargés.

C'est assez choquant et ennuyeux pour les utilisateurs, il vaut donc mieux le minimiser . Pire encore, lorsque ce bouton sur lequel vous étiez sur le point de cliquer se déplace soudainement et que vous cliquez sur un autre bouton à la place! CLS tente de rendre compte de ces changements de disposition.

Lab contre RUM

L'un des points clés à comprendre sur Core Web Vitals est qu'ils sont basés sur des métriques de terrain ou des métriques de l'utilisateur réel (RUM). Google utilise les données anonymisées des utilisateurs de Chrome pour commenter les métriques et les met à disposition dans le Chrome User Experience Report (CrUX) . Ces données sont ce qu'ils utilisent pour mesurer ces trois métriques pour les classements de recherche. Les données CrUX sont disponibles dans un certain nombre d'outils, y compris dans la console de recherche Google de votre site.

Le fait que les données RUM soient utilisées est une distinction importante car certaines de ces mesures (sauf FID) sont disponible dans des outils de performance Web synthétiques ou «basés sur le laboratoire» comme Lighthouse qui ont été la base de la surveillance des performances Web pour beaucoup dans le passé. Ces outils exécutent des chargements de page sur des réseaux et des périphériques simulés, puis vous indiquent quelles étaient les métriques pour ce test.

Donc, si vous exécutez Lighthouse sur votre machine de développement très puissante et obtenez de bons scores, cela ne reflète peut-être pas ce que l'expérience des utilisateurs dans le monde réel, et donc ce que Google utilisera pour mesurer l'expérience utilisateur de votre site Web.

LCP dépendra beaucoup des conditions du réseau et de la puissance de traitement des appareils utilisés (et de nombreux utilisateurs utilisent probablement beaucoup d'appareils moins puissants que vous ne le pensez! ). Un contrepoint cependant est que, pour de nombreux sites occidentaux au moins, nos mobiles ne sont peut-être pas aussi peu puissants que le suggèrent des outils tels que Lighthouse en mode mobile, car ils sont assez limités. Ainsi, vous remarquerez peut-être que vos données de terrain sur mobile sont meilleures que de tester avec cela (il y a quelques discussions sur la modification des paramètres mobiles de Lighthouse ).

De même, le FID dépend souvent de la vitesse du processeur et de la façon dont l'appareil peut gérer tout ce contenu que nous lui envoyons – que ce soit des images à traiter, des éléments à mettre en page sur la page et, bien sûr, tout ce JavaScript que nous aimons envoyer au navigateur pour le désabonnement

CLS est, en théorie, plus facile à mesurer dans les outils car il est moins sensible aux variations de réseau et de matériel, donc on pourrait penser qu'il n'est pas aussi sujet aux différences entre LAB et RUM – à l'exception de quelques considérations importantes que peut ne pas être évident au départ:

• Il est mesuré tout au long de la vie de la page et pas seulement pour le chargement de page comme le font les outils typiques, que nous explorerons plus loin dans cet article. Cela cause beaucoup de confusion lorsque les chargements de page simulés en laboratoire ont un CLS très faible, mais que le score CLS du champ est beaucoup plus élevé, en raison du CLS causé par le défilement ou d'autres changements après le chargement initial que les outils de test mesurent généralement.
• Il peut dépendre de la taille de la fenêtre du navigateur – généralement des outils comme PageSpeed ​​Insights, mesurent les mobiles et les ordinateurs de bureau, mais différents mobiles ont des tailles d'écran différentes et les ordinateurs de bureau sont souvent beaucoup plus grands que ces outils ( Web Page Test a récemment augmenté sa taille d'écran par défaut pour essayer de refléter plus précisément l'utilisation).
• Différents utilisateurs voient des choses différentes sur les pages Web . Bannières de cookies, contenu personnalisé comme les promotions, Adblockers, tests A / B pour ne citer que quelques éléments qui peuvent être différents, tous ont un impact sur le contenu dessiné et donc sur ce que les utilisateurs de CLS peuvent ressentir.
• Cela évolue toujours et l'équipe Chrome a été occupé à corriger les changements «invisibles» et autres qui ne devraient pas compter pour le CLS. Des changements plus importants sur la façon dont le CLS est réellement mesuré sont également en cours. Cela signifie que vous pouvez voir différentes valeurs CLS en fonction de la version de Chrome exécutée.

Utiliser le même nom pour les métriques dans les outils de test en laboratoire, quand ils peuvent ne pas refléter fidèlement les versions réelles est déroutant et certains suggèrent que nous devrions renommer tout ou partie de ces métriques dans Lighthouse pour distinguer ces métriques simulées des métriques RUM du monde réel qui alimentent les classements de Google.

Précédentes métriques de performances Web

Un autre point La confusion est que ces métriques sont nouvelles et différentes des métriques que nous utilisions traditionnellement dans le passé pour mesurer les performances du Web et qui sont mises en évidence par certains de ces outils, comme PageSpeed ​​Insights – un outil d'audit en ligne gratuit. Entrez simplement l'URL sur laquelle vous souhaitez effectuer un audit et cliquez sur Analyser. Quelques secondes plus tard, deux onglets (un pour mobile et un pour ordinateur de bureau) vous seront présentés contenant une mine d'informations:

En haut se trouve le grand score de performance de Lighthouse sur 100. Cela a été bien- connue au sein des communautés de performance Web depuis un certain temps maintenant et est souvent citée comme une mesure de performance clé pour viser et résumer la complexité de nombreuses mesures en un chiffre simple et facile à comprendre. Cela a un certain chevauchement avec l'objectif Core Web Vitals, mais il ne s'agit pas d'un résumé des trois Core Web Vitals (même les versions de laboratoire), mais d'une plus grande variété de métriques.

Actuellement, six métriques composent le score de performance de Lighthouse – y compris certains des Core Web Vitals et d'autres métriques:

• First Contentful Paint (FCP)
• SpeedIndex (SI)
• Largest Contentful Paint (LCP)
• Time to Interactive (TTI)
• Total Blocking Time (TBT)
• Cumulative Layout Shift (CLS)

Pour ajouter à la complexité, chacun de ces six est pondéré différemment dans le score de performance et CLS, bien qu'il soit l'un des Core Web Vitals, ne représente actuellement que 5% du score Lighthouse Performance (je parierai de l'argent sur cette augmentation peu de temps après la sortie de la prochaine itération de CLS). Tout cela signifie que vous pouvez obtenir un score de performance Lighthouse très élevé et de couleur verte et penser que votre site Web va bien, tout en ne dépassant toujours pas le seuil Core Web Vitals. Par conséquent, vous devrez peut-être recentrer vos efforts maintenant pour examiner ces trois métriques de base.

En passant au-delà du grand score vert de cette capture d'écran, nous passons aux données de terrain et nous obtenons un autre point de confusion: First Contentful Paint est affiché dans ces données de champ ainsi que les trois autres Core Web Vitals, bien qu'elles ne fassent pas partie des Core Web Vitals et, comme dans cet exemple, je trouve souvent qu'elles sont signalées comme un avertissement même si les autres passent tous. (Peut-être que les seuils pour cela ont besoin d'un peu d'ajustement?) FCP a-t-il manqué de peu d'être un Core Web Vital, ou peut-être qu'il semble simplement mieux équilibré avec quatre mesures? Cette section de données de champ est importante et nous y reviendrons plus tard.

Si aucune donnée de champ n'est disponible pour l'URL particulière testée, alors les données d'origine pour l'ensemble du domaine seront affichées à la place ( ceci est masqué par défaut lorsque les données de champ sont disponibles pour cette URL particulière, comme indiqué ci-dessus).

Après les données de champ, nous obtenons les données de laboratoire, et nous voyons les six métriques qui composent le score de performance en haut. Si vous cliquez sur la bascule en haut à droite, vous obtenez même un peu plus une description de ces métriques:

Comme vous pouvez le voir , les versions de laboratoire de LCP et CLS sont incluses ici et, comme elles font partie de Core Web Vitals, elles reçoivent une étiquette bleue pour les marquer comme très importantes. PageSpeed ​​Insights comprend également un lien de calcul utile pour voir l'impact de ces scores sur le score total en haut, et il vous permet de les ajuster pour voir ce que l'amélioration de chaque métrique aura sur votre score. Mais, comme je l'ai dit, le score de performance Web est susceptible de prendre un peu de recul pendant que les Core Web Vitals se prélassent dans la lueur de toute l'attention en ce moment.

Lighthouse effectue également près de 50 autres contrôles supplémentaires Opportunités et Diagnostics . Celles-ci n'ont pas d'impact direct sur le score, ni sur Core Web Vitals, mais peuvent être utilisées par les développeurs Web pour améliorer les performances de leur site . Ceux-ci sont également affichés dans PageSpeed ​​Insights sous toutes les mesures, donc juste hors de vue pour la capture d'écran ci-dessus. Considérez-les comme des suggestions sur la façon d'améliorer les performances, plutôt que comme des problèmes spécifiques qui doivent nécessairement être résolus.

Les diagnostics vous montreront l'élément LCP et les changements qui ont contribué à votre score CLS qui sont des éléments d'information très utiles lors de l'optimisation de votre Core Web Vitals!

Ainsi, alors que dans le passé, les défenseurs des performances Web se sont fortement concentrés sur les scores et les audits de Lighthouse, je vois cela se concentrer sur les trois métriques Core Web Vital – à moins pour la prochaine période pendant que nous nous occupons d'eux. Les autres mesures de Lighthouse, et le score global, sont toujours utiles pour optimiser les performances de votre site, mais les Core Web Vitals absorbent actuellement l'essentiel des nouvelles performances Web et des articles de blog SEO.

Votre site

Le moyen le plus simple d'obtenir un aperçu rapide des éléments essentiels du Web pour une URL individuelle, et pour toute l'origine, est de saisir une URL dans PageSpeed ​​Insights comme indiqué ci-dessus. Cependant, pour voir comment Google voit les Core Web Vitals pour l'ensemble de votre site, accédez à Google Search Console . Il s'agit d'un produit gratuit créé par Google qui vous permet de comprendre comment Google "voit" votre site dans son intégralité, y compris les Core Web Vitals de votre site (bien qu'il y ait quelques – dirons-nous – " frustrations " avec à quelle fréquence les données sont mises à jour ici).

Google Search Console a longtemps été utilisé par les équipes de référencement, mais avec l'entrée dont les développeurs de sites auront besoin pour traiter Core Web Vitals, les équipes de développement devraient également avoir accès à cet outil si elles ne l'ont pas pas déjà. Pour y accéder, vous aurez besoin d'un compte Google, puis pour vérifier votre propriété du site par divers moyens (placer un fichier dans votre serveur Web, ajouter un enregistrement DNS… etc.).

The Core Web Vitals report dans la Google Search Console vous donne un résumé de la façon dont votre site répond aux critères essentiels du Web au cours des 90 derniers jours:

Grand aperçu )

Idéalement, pour être considéré comme passant complètement les Core Web Vitals, vous voulez que toutes vos pages soient vertes ]sans ambres ni rouges. Même si l’ambre est un bon indicateur que vous êtes sur le point de passer, ce ne sont vraiment que les verts qui comptent, alors ne vous contentez pas du deuxième meilleur. Que vous ayez besoin de toutes les pages qui passent ou simplement de vos pages clés dépend de vous, mais souvent, il y aura des problèmes similaires sur de nombreuses pages, et les corriger pour le site peut aider à obtenir le nombre d'URL qui ne t passer à un niveau plus gérable où vous pouvez prendre ces décisions.

Au départ, Google va seulement appliquer le classement Core Web Vitals aux mobiles mais ce n'est sûrement qu'une question de temps avant qui se déploie également sur le bureau alors n'ignorez pas le bureau pendant que vous y êtes en train de réviser et de réparer vos pages.

En cliquant sur l'un des rapports, vous obtiendrez plus de détails sur les sites Web vitaux qui ne parviennent pas à être rencontré, puis un échantillon d'URL affectées. Google Search Console regroupe les URL dans des buckets pour, en théorie, vous permettre d’adresser des pages similaires ensemble. Vous pouvez ensuite cliquer sur une URL pour exécuter PageSpeed ​​Insights afin d'exécuter un audit rapide des performances sur l'URL particulière (y compris en affichant les données de champ Core Web Vitals pour cette page si elles sont disponibles). Vous corrigez ensuite les problèmes qu'il met en évidence, relancez PageSpeed ​​Insights pour confirmer que les métriques de laboratoire sont maintenant correctes, puis passez à la page suivante.

Cependant, une fois que vous commencez à regarder ce rapport Core Web Vitals (obsessionnel pour certains d'entre nous !), vous avez peut-être été frustré que ce rapport ne semble pas être mis à jour pour refléter votre travail acharné. Il semble se mettre à jour chaque jour au fur et à mesure que le graphique se déplace, mais il change souvent à peine, même une fois que vous avez publié vos correctifs. Pourquoi?

De même, les données du champ PageSpeed ​​Insights indiquent obstinément que cette URL et ce site échouent. Quelle est l'histoire ici alors?

Le rapport d'expérience utilisateur de Chrome (CrUX)

La raison pour laquelle les Web Vitals sont lents à mettre à jour, c'est que les données de terrain sont basées sur les derniers 28 jours de données dans Chrome User Experience Report (CrUX) et dans ce rapport, seulement le 75e centile de ces données. L'utilisation de 28 jours de données et les 75e centiles de données sont de bonnes choses, en ce sens qu'ils suppriment les écarts et les extrêmes pour donner un reflet plus précis des performances de votre site sans causer beaucoup de bruit difficile à interpréter.

Mesures de performance sont très sensibles au réseau et aux périphériques nous devons donc atténuer ce bruit pour obtenir la véritable histoire des performances de votre site Web pour la plupart des utilisateurs. Cependant, le revers de la médaille est qu'ils sont extrêmement lents à se mettre à jour, ce qui crée une boucle de rétroaction très lente à partir de la correction des problèmes, jusqu'à ce que vous voyiez les résultats de cette correction reflétés ici.

Le 75e centile (ou p75) en particulier est intéressant et le retard que cela crée, car je ne pense pas que cela soit bien compris. Il examine la métrique que 75% de vos visiteurs obtiennent pour les pages vues au cours de ces 28 jours pour chacun des Core Web Vitals.

Il s'agit donc du score Core Web Vital le plus élevé de 75% de nos utilisateurs ] (ou inversement le score Core Web Vitals le plus bas que 75% de vos visiteurs auront inférieur à). Ce n'est donc pas la moyenne de ces 75% d'utilisateurs, mais la pire valeur de cet ensemble d'utilisateurs.

Cela crée un retard dans le signalement qu'un non-percentile- la moyenne mobile basée ne le serait pas. Nous devrons faire un peu de calcul ici (je vais essayer de le garder au minimum), mais disons, par souci de simplicité, que tout le monde a eu un LCP de 10 secondes pour le mois dernier, et vous l'avez corrigé alors maintenant, il ne prend qu'une seconde, et disons que chaque jour vous avez eu exactement le même nombre de visiteurs chaque jour et qu'ils ont tous obtenu ce LCP.

Dans ce scénario trop simpliste, vous obtiendriez les métriques suivantes:

Vous pouvez donc voir que vous ne voyez pas vos améliorations drastiques dans le Score CrUX jusqu'au jour 22 quand soudainement il saute à la nouvelle valeur inférieure (une fois que nous avons franchi 75% de la moyenne de 28 jours – ce n'est pas un hasard!). Jusque-là, plus de 25% de vos utilisateurs étaient basés sur des données collectées avant le changement, et nous obtenons donc l'ancienne valeur de 10, et donc votre valeur p75 était bloquée à 10.

Par conséquent, il vous ressemble » Je n'ai fait aucun progrès pendant longtemps, alors qu'une moyenne moyenne (si elle était utilisée) montrerait un ralentissement progressif commençant immédiatement et ainsi des progrès pourraient effectivement être observés. Du côté positif, pour les derniers jours, la moyenne est en fait supérieure à la valeur p75 puisque p75, par définition, filtre complètement les extrêmes.

L'exemple du tableau ci-dessus, bien que massivement simplifié, explique une des raisons pour lesquelles beaucoup pourraient voir des graphiques Web Vitals comme ci-dessous, où un jour toutes vos pages franchissent un seuil puis sont bonnes ( woohoo! ):

Cela peut surprendre ceux qui s'attendent à des changements plus graduels (et instantanés) pendant que vous travaillez par le biais de problèmes de page, et comme certaines pages sont visitées plus souvent que d'autres. Dans le même ordre d'idées, il n'est pas rare non plus de voir votre graphique de Search Console passer par une période ambre en fonction de vos corrections et de leur impact sur les seuils, avant d'atteindre cette douce et douce couleur verte: [19659129] Graphique montrant principalement le rouge, qui passe soudainement à l'ambre, puis au rouge. « />

Dave Smart a mené une expérience fascinante Suivi des modifications dans les données Web vitales du rapport de la Search Console où il voulait voir comment rapidement, il a fallu mettre à jour les graphiques. Il n'a pas pris en compte la portion du 75e centile de CrUX (ce qui rend le manque de mouvement dans certains de ses graphiques plus logique), mais reste une expérience fascinante dans la vie réelle sur la mise à jour de ce graphique et vaut bien une lecture! [19659003] Ma propre expérience est que cette méthodologie p75 de 28 jours n'explique pas complètement le décalage dans le rapport Core Web Vitals, et nous discuterons d'autres raisons potentielles dans un instant.

Donc est-ce le mieux que vous puissiez faire, apporter les correctifs, puis attendre patiemment, en tapotant vos doigts, jusqu'à ce que CrUX juge vos correctifs comme valables et met à jour le graphique dans Search Console et PageSpeed ​​Insights? Et s'il s'avère que vos correctifs n'étaient pas assez bons, recommencer tout le cycle? En cette journée de feedback instantané pour satisfaire nos envies, et de boucles de feedback serrées pour les développeurs pour améliorer la productivité ce n'est pas très satisfaisant du tout!

Eh bien, il y a certaines choses que vous pouvez faire en attendant pour essayer de voir si des correctifs auront l'impact escompté.

Explorer les données Crux plus en détail

Puisque le cœur de la mesure est les données CrUX, approfondissons-en un peu plus et voyons ce qu'il peut d'autre dites-nous. En revenant à PageSpeed ​​Insights, nous pouvons voir qu'il affiche non seulement la valeur p75 pour le site, mais également le pourcentage de pages vues dans chacun des compartiments vert, orange et rouge indiqués dans les barres de couleur ci-dessous:

La capture d'écran ci-dessus montre que CLS échoue au score Core Web Vitals avec une valeur p75 de 0,11, ce qui est au-dessus de la limite de réussite de 0,1. Cependant, bien que la couleur de la police soit rouge, il s'agit en fait d'un classement orange (car le rouge serait au-dessus de 0,25). Plus intéressant encore, la barre verte est à 73% – une fois qu'elle atteint 75%, cette page passe le Core Web Vitals.

Bien que vous ne puissiez pas voir les valeurs CrUX historiques, vous pouvez le surveiller au fil du temps. S'il passe à 74% demain, nous allons dans la bonne direction (sous réserve de fluctuations!) Et pouvons espérer atteindre la magie des 75% bientôt. Pour les valeurs plus éloignées, vous pouvez vérifier périodiquement et voir l'augmentation puis projeter le moment où vous pourriez commencer à apparaître comme passant.

CrUX est également disponible en tant qu'API gratuite pour obtenir des chiffres plus précis pour ces pourcentages. Une fois que vous vous êtes inscrit pour une clé API vous pouvez l'appeler avec une commande curl comme celle-ci (en remplaçant API_KEY, formFactor et URL selon le cas):

 curl -s --request POST 'https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY' 
    --header 'Accepter: application / json' 
    --header 'Content-Type: application / json' 
    --data '{"formFactor": "PHONE", "url": "https://www.example.com"}'

Et vous obtiendrez une réponse JSON, comme celle-ci:

 {
  "enregistrer": {
    "clé": {
      "formFactor": "TÉLÉPHONE",
      "url": "https://www.example.com/"
    },
    "metrics": {
      "cumulative_layout_shift": {
        "histogramme": [
          {
            "start": "0.00",
            "end": "0.10",
            "density": 0.99959769344240312
          },
          {
            "start": "0.10",
            "end": "0.25",
            "density": 0.00040230655759688886
          },
          {
            "start": "0.25"
          }
        ],
        "percentiles": {
          "p75": "0,00"
        }
      },
      "first_contentful_paint": {
        ...
      }
    }
  },
  "urlNormalizationDetails": {
    "originalUrl": "https://www.example.com",
    "normalizedUrl": "https://www.example.com/"
  }
}

Incidemment, si ci-dessus vous fait un peu peur et que vous voulez un moyen plus rapide d'obtenir un aperçu de ces données pour une seule URL, alors PageSpeed ​​Insights renvoie également cette précision que vous pouvez voir en ouvrant DevTools puis en exécutant votre PageSpeed ​​Insights test, et trouver l'appel XHR qu'il fait:

Il y a également un explorateur d'API CrUX interactif qui vous permet d'effectuer des exemples de requêtes de l'API CrUX. Cependant, pour un appel régulier de l'API, il est généralement plus facile d'obtenir une clé gratuite et d'utiliser Curl ou un autre outil d'API.

L'API peut également être appelée avec une «origine», au lieu d'une URL, auquel cas elle sera donnez la valeur récapitulative de toutes les visites de pages dans ce domaine. PageSpeed ​​Insights expose ces informations, ce qui peut être utile si votre URL ne dispose pas d'informations CrUX, contrairement à Google Search Console. Google n'a pas indiqué (et il est peu probable que!) Exactement l'impact des Core Web Vitals sur le classement . Le score au niveau de l'origine aura-t-il un impact sur les classements ou uniquement sur les scores des URL individuelles? Ou, comme PageSpeed ​​Insights, Google reviendra-t-il aux scores de niveau d'origine lorsque les données URL individuelles n'existent pas? Difficile à savoir pour le moment et le seul indice pour l'instant est celui-ci dans la FAQ:

Q : Comment est calculé un score pour une URL qui a été récemment publiée et qui n'a pas encore généré 28 jours

A : De la même manière que la Search Console rapporte les données d'expérience des pages, nous pouvons utiliser des techniques telles que le regroupement de pages similaires et calculer les scores en fonction de cette agrégation. Cela s'applique aux pages qui reçoivent peu ou pas de trafic, de sorte que les petits sites sans données de terrain n'ont pas à s'inquiéter.

L'API CrUX peut être appelée par programmation, et Rick Viscomi de Google CrUX L'équipe a créé un moniteur Google Sheets vous permettant de vérifier en masse les URL ou les origines, et même de suivre automatiquement les données CrUX au fil du temps si vous souhaitez surveiller de près un certain nombre d'URL ou d'origines. Clonez simplement la feuille, allez dans l'éditeur Tools → Script puis entrez une propriété de script de CRUX_API_KEY avec votre clé (cela doit être fait dans l'éditeur hérité), puis exécutez le script et il appellera l'API CrUX pour les URL ou origines données et ajoutera des lignes au bas de la feuille avec les données. Cela peut ensuite être exécuté périodiquement ou programmé pour s'exécuter régulièrement.

Je l'ai utilisé pour vérifier toutes les URL d'un site avec une mise à jour lente du rapport Core Web Vitals dans Google Search Console et cela a confirmé que CrUX n'avait pas de données pour beaucoup de les URL et la plupart des autres étaient passées, ce qui montre encore une fois que le rapport de la console de recherche Google est en retard – même à partir des données CrUX sur lesquelles il est censé être basé. Je ne sais pas si cela est dû à des URL qui avaient échoué auparavant mais qui n'ont pas assez de trafic pour obtenir des données CrUX mises à jour indiquant leur passage, ou si cela est dû à autre chose, mais cela me prouve que ce rapport est certainement lent .

Je soupçonne qu'une grande partie de cela est due aux URL sans données dans CrUX et Google Search faisant de son mieux pour fournir une valeur pour eux. Ce rapport est donc un excellent point de départ pour obtenir un aperçu de votre site et un suivi pour l’avenir, mais ce n’est pas un excellent rapport pour résoudre les problèmes pour lesquels vous souhaitez obtenir des commentaires plus immédiats.

Pour ceux qui veulent approfondir dans CrUX encore plus, il existe tableaux mensuels de données CrUX disponibles dans BigQuery (au niveau de l'origine uniquement, donc pas pour les URL individuelles) et Rick a également expliqué comment créer un Tableau de bord CrUX basé sur ce qui peut être un bon moyen de surveiller les performances globales de votre site Web au fil des mois.

Autres informations sur les données Crux

Donc, avec ce qui précède, vous devriez avoir une bonne compréhension de CrUX ensemble de données, pourquoi certains des outils qui l'utilisent semblent lents et errants ic pour mettre à jour, et aussi comment l'explorer un peu plus. Mais avant de passer à des alternatives, il y a d'autres choses à comprendre sur CrUX pour vous aider à vraiment comprendre les données qu'il affiche. Voici donc une collection d’autres informations utiles que j’ai recueillies sur CrUX par rapport à Core Web Vitals.

CrUX est Chrome uniquement . Tous ces utilisateurs iOS et autres navigateurs (Desktop Safari, Firefox, Edge… etc.), sans parler des navigateurs plus anciens (Internet Explorer – dépêchez-vous et disparaissez-vous!) Ne voient pas leur expérience utilisateur reflétée dans les données CrUX et ainsi de suite. sur la vue de Google sur Core Web Vitals.

Maintenant, l'utilisation de Chrome est très élevée (mais peut-être pas pour les visiteurs de votre site?), et dans la plupart des cas, les problèmes de performances qu'il met en évidence affecteront également ces autres navigateurs, mais c'est quelque chose être au courant. And it does feel a little “icky” to say the least, that the monopoly position of Google in search, is now encouraging people to optimize for their browser. We’ll talk below about alternative solutions for this limited view.

The version of Chrome being used will also have an impact as these metrics (CLS in particular) are still evolving as well as bugs are being found and fixed. This adds another dimension of complexity to understanding the data. There have been continual improvements to CLS in recent versions of Chromewith a redefinition of CLS potentially landing in Chrome 92. Again the fact that field data is being used means it might take some time for these changes to feed through to users, and then into the CrUX data.

CrUX is only for users logged into Chromeor to quote the actual definition:

“[CrUX is] aggregated from users who have opted-in to syncing their browsing history, have not set up a Sync passphrase, and have usage statistic reporting enabled.”

— Chrome User Experience ReportGoogle Developers

So if you’re looking for information on a site mostly visited from corporate networks, where such settings are turned off by central IT policies, then you might not be seeing much data — especially if those poor corporate users are still being forced to use Internet Explorer too!

CrUX includes all pages, includin g those not typically surfaced to Google Search such as “noindexed / robboted / logged in pages will be included” (though there are minimum thresholds for a URL and origin to be exposed in CrUX). Now those categories of pages will likely not be included in Google Search results and so the ranking impact on them is probably unimportant, but they still will be included in CrUX. The Core Web Vitals report in Google Search Console however seems to only show indexed URLsso they will not show up there.

The origin figure shown in PageSpeed Insights and in the raw CrUX data will include those non-indexed, non-public pages, and as I mentioned above, we’re not sure of the impact of that. A site I work on has a large percentage of visitors visiting our logged-in pages, and while the public pages were very performant the logged-in pages were not, and that severely skewed the origin Web Vitals scores.

The CrUX API can be used to get the data of these logged-in URLsbut tools like PageSpeed Insights cannot (since they run an actual browser and so will be redirected to the login pages). Once we saw that CrUX data and realized the impact, we fixed those, and the origin figures have started to drop down but, as ever, it’s taking time to feed through.

Noindexed or logged-in pages are also often “apps” as well, rather than individual collections of pages so may be using a Single Page Application methodology with one real URL, but many different pages underneath that. This can impact CLS in particular due to it being measured over the whole life of the page (though hopefully the upcoming changes to CLS will help with that).

As mentioned previously, the Core Web Vitals report in Google Search Console, while based on CrUX, is definitely not the same data. As I stated earlier, I suspect this is primarily due to Google Search Console attempting to estimate Web Vitals for URLs where no CrUX data exists. The sample URLs in this report are also out of whack with the CrUX data.

I’ve seen many instances of URLs that have been fixed, and the CrUX data in either PageSpeed Insights, or directly via the API, will show it passing Web Vitals, yet when you click on the red line in the Core Web Vitals report and get sample URLs these passing URLs will be included as if they are failing. I’m not sure what heuristics Google Search Console uses for this grouping, or how often it and sample URLs are updated, but it could do with updating more often in my opinion!

CrUX is based on page views. That means your most popular pages will have a large influence on your origin CrUX data. Some pages will drop in and out of CrUX each day as they meet these thresholds or not, and perhaps the origin data is coming into play for those? Also if you had a big campaign for a period and lots of visits, then made improvements but have fewer visits since, you will see a larger proportion of the older, worse data.

CrUX data is separated into MobileDesktop and Tablet — though only Mobile and Desktop are exposed in most tools. The CrUX API and BigQuery allows you to look at Tablet data if you really want to, but I’d advise concentrating on Mobile and then Desktop. Also, note in some cases (like the CrUX API) it’s marked as PHONE rather than MOBILE to reflect it’s based on the form factor, rather than that the data is based on being on a mobile network.

All in all, a lot of these issues are impacts of field (RUM) data gathering, but all these nuances can be a lot to take on when you’ve been tasked with “fixing our Core Web Vitals”. The more you understand how these Core Web Vitals are gathered and processed, the more the data will make sense, and the more time you can spend on fixing the actual issues, rather than scratching your head wondering why it’s not reporting what you think it should be.

Getting Faster Feedback

OK, so by now you should have a good handle on how the Core Web Vitals are collected and exposed through the various tools, but that still leaves us with the issue of how we can get better and quicker feedback. Waiting 21–28 days to see the impact in CrUX data — only to realize your fixes weren’t sufficient — is way too slow. So while some of the tips above can be used to see if CrUX is trending in the right direction, it’s still not ideal. The only solution, therefore, is to look beyond CrUX in order to replicate what it’s doing, but expose the data faster.

There are a number of great commercial RUM products on the market that measure user performance of your site and expose the data in dashboards or APIs to allow you to query the data in much more depth and at much more granular frequency than CrUX allows. I’ll not give any names of products here to avoid accusations of favoritism, or offend anyone I leave off! As the Core Web Vitals are exposed as browser APIs (by Chromium-based browsers at least, other browsers like Safari and Firefox do not yet expose some of the newer metrics like LCP and CLS), they should, in theory, be the same data as exposed to CrUX and therefore to Google — with the same above caveats in mind!

For those without access to these RUM products, Google has also made available a Web Vitals JavaScript librarywhich allows you to get access to these metrics and report them back as you see fit. This can be used to send this data back to Google Analytics by running the following script on your web pages:

Now I realize the irony of adding another script to measure the impact of your website, which is probably slow in part because of too much JavaScript, but as you can see above, the script is quite small and the library it loads is only a further 1.7 kB compressed (4.0 kB uncompressed). Additionally, as a module (which will be ignored by older browsers that don’t understand web vitals), its execution is deferred so shouldn’t impact your site too much, and the data it can gather can be invaluable to help you investigate your Core Web Vital, in a more real-time manner than the CrUX data allows.

The script registers a function to send a Google Analytics event when each metric becomes available. For FCP and TTFB this is as soon as the page is loaded, for FID after the first interaction from the user, while for LCP and CLS it is when the page is navigated away from or backgrounded and the actual LCP and CLS are definitely known. You can use developer tools to see these beacons being sent for that page, whereas the CrUX data happens in the background without being exposed here.

The benefit of putting this data in a tool like Google Analytics is you can slice and dice the data based on all the other information you have in there, including form factor (desktop or mobile), new or returning visitors, funnel conversions, Chrome version, and so on. And, as it’s RUM data, it will be affected by real usage — users on faster or slower devices will report back faster or slower values — rather than a developer testing on their high spec machine and saying it’s fine.

At the same time, you need to bear in mind that the reason the CrUX data is aggregated over 28 days, and only looks at the 75th percentile is to remove the variance. Having access to the raw data allows you to see more granular databut that means you’re more susceptible to extreme variations. Still, as long as you keep that in mind, keeping early access to data can be very valuable.

Google’s Phil Walton created a Web-Vitals dashboardthat can be pointed at your Google Analytics account to download this data, calculate the 75th percentile (so that helps with the variations!) and then display your Core Web Vitals score, a histogram of information, a time series of the data, and your top 5 visited pages with the top elements causing those scores.

Using this dashboard, you can filter on individual pages (using a ga:pagePath==/page/path/index.html filter), and see a very satisfying graph like this within a day of you releasing your fix, and know your fix has been successful and you can move on to your next challenge!:

With a little bit more JavaScript you can also expose more information (like what the LCP element is, or which element is causing the most CLS) into a Google Analytics Custom Dimension. Phil wrote an excellent Debug Web Vitals in the field post on this which basically shows how you can enhance the above script to send this debug information as well, as shown in this version of the script.

These dimensions can also be reported in the dashboard (using ga:dimension1 as the Debug dimension field, assuming this is being sent back in Google Analytics Customer Dimension 1 in the script), to get data like this to see the LCP element as seen by those browsers:

As I said previously, commercial RUM products will often expose this sort of data too (and more!), but for those just dipping their toe in the water and not ready for the financial commitment of those products, this at least offers the first dabble into RUM-based metrics and how useful they can be to get that crucial faster feedback on the improvements you’re implementing. And if this whets your appetite for this information, then definitely look at the other RUM products out there to see how they can help you, too.

When looking at alternative measurements and RUM products, do remember to circle back round to what Google is seeing for your site, as it may well be different. It would be a shame to work hard on performance, yet not get all the ranking benefits of this at the same time! So keep an eye on those Search Console graphs to ensure you’re not missing anything.

Conclusion

The Core Web Vitals are an interesting set of key metrics looking to represent the user experience of browsing the web. As a keen web performance advocate, I welcome any push to improve the performance of sites and the ranking impact of these metrics has certainly created a great buzz in the web performance and SEO communities.

While the metrics themselves are very interesting, what’s perhaps more exciting is the use of CrUX data to measure these. This basically exposes RUM data to websites that have never even considered measuring site performance in the field in this way before. RUM data is what users are actually experiencingin all their wild and varied setups, and there is no substitute for understanding how your website is really performing and being experienced by your users.

But the reason we’ve been so dependent on lab data for so long is because RUM data is noisy. The steps CrUX takes to reduce this does help to give a more stable view, but at the cost of it making it difficult to see recent changes.

Hopefully, this post goes some way to explaining the various ways of accessing the Core Web Vitals data for your website, and some of the limitations of each method. I also hope that it goes some way to explaining some of the data you’ve been struggling to understand, as well as suggesting some ways to work around those limitations.

Happy optimizing!

(vf, il)