Mesurer et optimiser pour Google Core Web Vitals : un guide technique de référencement

La collecte de données sur les performances de votre site est la première étape vers une expérience utilisateur exceptionnelle. Au fil des années, Google a fourni divers outils pour évaluer et rendre compte des performances Web.

Parmi eux figurent les Core Web Vitals, un ensemble de signaux de performance que Google considère comme essentiels à toutes les expériences Web.

Cet article couvre l'ensemble actuel des Core Web Vitals ainsi que des conseils et outils clés pour améliorer vos performances Web afin d'offrir une bonne expérience de page aux utilisateurs.

Un regard sur l'évolution de la performance Web

Il est révolu le temps où améliorer les performances du site était simple.

Dans le passé, les ressources surchargées et les connexions lentes freinaient souvent les sites Web. Mais vous pourriez surpasser vos concurrents en compressant certaines images, en activant la compression de texte ou en réduisant vos feuilles de style et vos modules JavaScript.

Aujourd’hui, les vitesses de connexion sont plus rapides. La plupart des ressources sont compressées par défaut et de nombreux plugins gèrent la compression d'images, le déploiement de cache, etc.

La quête de Google pour un Web plus rapide persiste. PageSpeed ​​Insights (PSI) est toujours disponible sur web.dev, constituant le meilleur outil pour évaluer le chargement de pages individuelles.

Bien que beaucoup estiment que les notes PSI sont inutilement punitives, elles restent ce qui se rapproche le plus de la façon dont Google pourrait évaluer et classer les sites via des signaux de vitesse de page.

Pour réussir la dernière itération du test de vitesse de page de Google, vous devrez satisfaire à l'évaluation Core Web Vitals.

Comprendre les éléments essentiels du Web

Les Core Web Vitals sont un ensemble de métriques intégrées aux signaux de recherche plus larges sur l’expérience de page introduits en 2021. Chaque métrique « représente une facette distincte de l’expérience utilisateur, est mesurable sur le terrain et reflète l’expérience du monde réel d’un utilisateur critique ». résultat centré », selon Google.

L’ensemble actuel de métriques Core Web Vitals comprend :

• Première peinture de contenu
• Premier délai d'entrée (à remplacer par Interaction avec la peinture suivante)
• Interaction avec la peinture suivante
• Temps jusqu'au premier octet
• La plus grande peinture de contenu
• Changement de disposition cumulatif

Web.dev explique le fonctionnement de chaque métrique comme suit.

Première peinture de contenu (FCP)

« La métrique First Contentful Paint (FCP) mesure le temps écoulé entre le début du chargement de la page et le moment où une partie du contenu de la page est affichée à l'écran. Pour cette métrique, le « contenu » fait référence au texte, aux images (y compris les images d’arrière-plan), aux éléments <svg> ou aux éléments <canvas> non blancs.

Ce que cela signifie pour les référenceurs techniques

FCP est assez facile à comprendre. Au fur et à mesure du chargement d'une page Web, certains éléments arrivent (ou « sont peints ») avant d'autres. Dans ce contexte, « peindre » signifie rendu à l’écran.

Une fois qu'une partie de la page a été rendue – disons que la barre de navigation principale se charge avant les autres éléments – le FCP sera enregistré à ce stade.

Pensez-y à la rapidité avec laquelle la page commence à se charger visiblement pour les utilisateurs. Le chargement de la page ne sera pas terminé, mais il aura commencé.

Délai de première entrée (FID)

« FID mesure le temps écoulé entre le moment où un utilisateur interagit pour la première fois avec une page (c'est-à-dire lorsqu'il clique sur un lien, appuie sur un bouton ou utilise un contrôle personnalisé alimenté par JavaScript) jusqu'au moment où le navigateur est réellement en mesure de commencer. traiter les gestionnaires d’événements en réponse à cette interaction.

Ce que cela signifie pour les référenceurs techniques

FID est une métrique de réactivité à l’interaction utilisateur qui sera remplacée par Interaction to Next Paint (INP) en mars 2024.

Si un utilisateur interagit avec un élément de la page (c'est-à-dire un lien, un tri d'un tableau ou une navigation à facettes), combien de temps faudra-t-il au site pour commencer à traiter cette demande ?

Interaction avec la peinture suivante (INP)

« INP est une mesure qui évalue la réactivité globale d'une page aux interactions de l'utilisateur en observant la latence de toutes les interactions de clic, d'appui et de clavier qui se produisent tout au long de la durée de vie de la visite d'un utilisateur sur une page. La valeur finale de l’INP correspond à l’interaction la plus longue observée, en ignorant les valeurs aberrantes.

Ce que cela signifie pour les référenceurs techniques

Comme mentionné, INP remplacera FID en tant que Core Web Vital en mars 2024.

INP prend en compte des informations plus approfondies (remontant apparemment au clavier) et est probablement plus détaillé et sophistiqué.

Temps jusqu'au premier octet (TTFB)

"TTFB est une métrique qui mesure le temps entre la demande d'une ressource et le moment où le premier octet d'une réponse commence à arriver."

Ce que cela signifie pour les référenceurs techniques

Une fois qu'une « ressource » (c'est-à-dire une image intégrée, un module JavaScript, une feuille de style CSS, etc.) est demandée, combien de temps faudra-t-il au site pour commencer à fournir cette ressource ?

Disons que vous visitez une page Web et que sur cette page se trouve une image intégrée. Le chargement commence mais n'est pas encore terminé. Combien de temps faut-il pour que le tout premier octet de cette image soit transmis du serveur au client (navigateur Web) ?

La plus grande peinture de contenu (LCP)

"La métrique Largest Contentful Paint (LCP) rapporte le temps de rendu de la plus grande image ou bloc de texte visible dans la fenêtre, par rapport au moment où la page a commencé à se charger."

Ce que cela signifie pour les référenceurs techniques

Le LCP est l’une des mesures les plus importantes mais aussi la plus difficile à satisfaire.

Une fois que la plus grande partie du média visuel (c'est-à-dire texte ou image) est chargée, le LCP est enregistré.

Vous pouvez lire ceci ainsi : combien de temps faut-il pour que la grande majorité du contenu principal d'une page se charge ?

Peut-être qu'il y a encore des petits éléments qui se chargent plus bas sur la page et des choses que la plupart des utilisateurs ne remarqueront pas.

Mais, au moment où le LCP est enregistré, la grande partie évidente de votre page est chargée. Si cela prend trop de temps, vous échouerez à la vérification LCP.

Changement de mise en page cumulatif (CLS)

« CLS est une mesure de la plus grande explosion de scores de changement de mise en page pour chaque changement de mise en page inattendu qui se produit pendant toute la durée de vie d'une page.

Un changement de disposition se produit chaque fois qu'un élément visible change de position d'une image rendue à la suivante. (Voir ci-dessous pour plus de détails sur la façon dont les scores de changement de disposition individuels sont calculés.)

Une rafale de changements de disposition, appelée fenêtre de session, se produit lorsqu'un ou plusieurs changements de disposition individuels se produisent en succession rapide avec moins d'une seconde entre chaque changement et un maximum de 5 secondes pour la durée totale de la fenêtre.

La plus grande rafale est la fenêtre de session avec le score cumulé maximum de tous les changements de disposition au sein de cette fenêtre.

Ce que cela signifie pour les référenceurs techniques

À l’époque, lorsque l’optimisation de la vitesse des pages était plus simple, de nombreux propriétaires de sites ont réalisé qu’ils pouvaient atteindre des vitesses de page incroyablement élevées en différant simplement toutes les ressources bloquant le rendu (généralement les feuilles CSS et les modules JavaScript).

C'était excellent pour accélérer le chargement des pages, mais cela rendait le Web une expérience de navigation plus problématique et ennuyeuse.

Si votre CSS – qui contrôle tout le style de votre page – est différé, alors le contenu de la page peut se charger avant que les règles CSS ne soient appliquées.

Cela signifie que le contenu de votre page se chargera sans style, puis sautera un peu au fur et à mesure du chargement du CSS.

C'est vraiment ennuyeux si vous chargez une page et cliquez sur un lien, mais ensuite le lien saute et vous cliquez sur le mauvais lien.

Si vous êtes un peu TOC comme moi, de telles expériences sont absolument exaspérantes (même si elles ne coûtent que quelques secondes).

En raison des propriétaires de sites qui tentaient de « jouer » sur les évaluations de vitesse des pages en différant toutes les ressources, Google avait besoin d'une contre-mesure, qui compenserait tous les gains de vitesse des pages par rapport au déficit d'expérience utilisateur.

Entrez le décalage de mise en page cumulatif (CLS). Il s’agit d’un client délicat, qui veut gâcher votre journée si vous essayez d’appliquer à grande échelle des augmentations de vitesse de page sans penser à vos utilisateurs.

CLS analysera essentiellement le chargement de vos pages pour détecter les changements problématiques et les règles CSS retardées.

S'il y en a trop, vous échouerez à l'évaluation Core Web Vitals même si vous avez satisfait à toutes les mesures liées à la vitesse.

Évaluation de vos Core Web Vitals pour de meilleurs résultats UX et SEO

L'un des meilleurs moyens d'analyser les performances d'une seule page Web consiste à la charger dans PageSpeed ​​Insights. La vue est divisée en une combinaison de :

• Données au niveau de l'URL.
• Données d'origine (au niveau du domaine).
• Données de laboratoire.
• Données de terrain.

Pour comprendre cela, nous devons regarder un exemple :

https://pagespeed.web.dev/analysis/https-techcrunch-com/zo8d0t4x1p?form_factor=mobile

Ici, nous pouvons voir les évaluations de vitesse et les mesures de la page d'accueil de TechCrunch.

Ci-dessus, vous pouvez voir que l’évaluation Core Web Vitals a échoué.

Dans un site Web axé sur les mobiles, il est important de sélectionner l'onglet Résultats mobiles , qui doit être affiché par défaut (ce sont les résultats qui comptent vraiment).

Sélectionnez le bouton Origine pour afficher la moyenne des données générales sur le domaine de votre site plutôt que uniquement sur la page d'accueil (ou sur la page que vous souhaitez analyser).

Plus bas sur la page, vous verrez l’ancien indice de vitesse numérique familier :

Alors, quelle est la différence entre la nouvelle évaluation Core Web Vitals et l’ancienne évaluation de la vitesse des pages ?

Essentiellement, la nouvelle évaluation Core Web Vitals (Réussite/Échec) est basée sur des données de terrain (utilisateur réel).

L'ancienne note numérique est basée sur des analyses mobiles simulées et des données de laboratoire, qui ne sont que des estimations.

Essentiellement, Google est passé à l'évaluation Core Web Vitals en termes de modification des classements de recherche.

Pour être clair, les données de laboratoire simulées peuvent donner une bonne idée de ce qui ne va pas, mais Google n'utilise pas cette note numérique dans ses algorithmes de classement.

À l’inverse, l’évaluation Core Web Vitals n’offre pas beaucoup d’informations granulaires. Cependant, cette évaluation est prise en compte dans les algorithmes de classement de Google.

Ainsi, votre objectif principal est d'utiliser les diagnostics de laboratoire plus riches afin de réussir éventuellement l'évaluation Core Web Vitals (dérivée via les données de terrain).

N'oubliez pas que lorsque vous apportez des modifications à votre site, même si la note numérique peut immédiatement observer des changements, vous devrez attendre que Google extraie davantage de données de terrain avant de pouvoir éventuellement réussir l'évaluation Core Web Vitals.

Vous remarquerez que l'évaluation Core Web Vitals et l'ancienne évaluation de la vitesse des pages utilisent certaines des mêmes mesures.

Par exemple, les deux font référence à First Contentful Paint (FCP), à Largest Contentful Paint (LCP) et à Cumulative Layout Shift (CLS).

D'une certaine manière, les types de mesures examinées par chaque système de notation sont assez similaires. C'est le niveau de détail et la source des données examinées qui sont différents.

Vous devez viser à réussir l’évaluation Core Web Vitals basée sur le terrain. Cependant, comme les données ne sont pas trop riches, vous souhaiterez peut-être tirer parti des données et des diagnostics de laboratoire traditionnels pour progresser.

L'espoir est que vous puissiez réussir l'évaluation Core Web Vitals en abordant les opportunités et les diagnostics du laboratoire. Mais rappelez-vous que ces deux tests ne sont pas intrinsèquement liés.

Évaluation de vos CWV via PageSpeed ​​Insights

Maintenant que vous connaissez les principales métriques Core Web Vitals et comment elles peuvent techniquement être satisfaites, il est temps de passer en revue un exemple.

Revenons à notre examen de TechCrunch :

https://pagespeed.web.dev/analysis/https-techcrunch-com/zo8d0t4x1p?form_factor=mobile

Ici, le FID est satisfait et l’INP n’échoue que de peu.

CLS a quelques problèmes, mais les principaux problèmes concernent LCP et FCP.

Voyons ce que PageSpeed ​​Insights a à dire en termes d' opportunités et de diagnostics .

Nous devons maintenant passer des données de terrain aux données de laboratoire et tenter d'isoler tous les modèles susceptibles d'avoir un impact sur les Core Web Vitals :

Ci-dessus, vous pouvez voir une petite sous-navigation dans le coin supérieur droit encadrée en vert.

Vous pouvez l'utiliser pour affiner les différentes opportunités et diagnostics à certaines métriques Core Web Vitals.

Dans ce cas, cependant, les données racontent une histoire très claire sans se limiter.

Premièrement, on nous dit de réduire le JavaScript inutilisé. Cela signifie que parfois JavaScript est chargé sans être exécuté.

Il existe également des notes pour réduire les CSS inutilisés. En d’autres termes, certains styles CSS sont en cours de chargement, qui ne sont pas appliqués (problème similaire).

On nous demande également d'éliminer les ressources bloquant le rendu, qui sont presque toujours liées aux modules JavaScript et aux feuilles CSS.

Les ressources bloquant le rendu doivent être différées pour les empêcher de bloquer le chargement d'une page. Cependant, comme nous l’avons déjà vu, cela pourrait perturber la notation CLS.

Pour cette raison, il serait sage de commencer à élaborer à la fois un CSS critique et un chemin de rendu JavaScript critique. Cela intégrera le JavaScript et le CSS nécessaires au-dessus de la ligne de flottaison tout en différant le reste.

Cette approche permet au propriétaire du site de satisfaire les demandes de chargement de pages tout en s'équilibrant avec la métrique CLS. Ce n'est pas une chose facile à faire et nécessite généralement un développeur Web expérimenté.

Puisque nous avons également trouvé du CSS et du JavaScript inutilisés, nous pouvons également émettre un audit général du code JavaScript pour voir si JavaScript pourrait être déployé de manière plus intelligente.

Revenons aux Opportunités et aux Diagnostics :

Maintenant, nous voulons nous concentrer sur le diagnostic. Google limite délibérément ces vérifications en raison de mauvaises connexions 4G, de sorte que des éléments tels que le travail du fil principal semblent si longs (17 secondes).

Ceci est délibéré afin de satisfaire les utilisateurs disposant d'une faible bande passante et/ou d'appareils lents, courants dans le monde entier.

Je souhaite attirer votre attention ici sur « Réduire le travail du thread principal ». Cette entrée unique est souvent une mine d’or d’informations.

Par défaut, la plupart des tâches de rendu et d'exécution de script (JavaScript) d'une page Web sont transmises via le thread de traitement principal du navigateur Web du client (un seul thread de traitement). Vous pouvez comprendre comment cela provoque d’importants goulots d’étranglement lors du chargement des pages.

Même si tout votre JavaScript est parfaitement minifié et envoyé rapidement au navigateur de l'utilisateur, il doit attendre par défaut dans une file d'attente de traitement à un seul thread, ce qui signifie qu'un seul script peut être exécuté à la fois.

Ainsi, envoyer rapidement des charges de JavaScript à votre utilisateur équivaut à tirer une lance à incendie sur un mur de briques avec un espace d'un centimètre.

Bon travail, mais tout ne se fera pas !

De plus en plus, Google fait de la réactivité côté client sa responsabilité. Aimez-le ou regroupez-le, c'est comme ça (vous feriez donc mieux de vous familiariser).

Vous pourriez dire avec frustration : « Pourquoi est-ce comme ça !? Les navigateurs Web ont accès à plusieurs threads de traitement depuis des années, même les navigateurs mobiles ont rattrapé leur retard. Il n’est pas nécessaire que les choses soient aussi gênantes, n’est-ce pas ?

En fait, oui. Certains scripts s'appuient sur la sortie d'autres scripts avant de pouvoir s'exécuter eux-mêmes.

Selon toute vraisemblance, si tous les navigateurs commençaient soudainement à traiter tout le JavaScript en parallèle, dans le désordre, la majeure partie du Web planterait et brûlerait probablement.

Il y a donc une bonne raison pour laquelle l’exécution de scripts séquentiels est le comportement par défaut des navigateurs Web modernes. Je continue d’insister sur le mot « par défaut ». Pourquoi donc?

C'est parce qu'il existe d'autres options. La première consiste à empêcher le navigateur du client de traiter des scripts en les traitant au nom de l'utilisateur. C'est ce qu'on appelle le rendu côté serveur (SSR).

C'est un outil puissant pour démêler les nœuds d'exécution JavaScript côté client mais aussi très coûteux.

Votre serveur doit traiter toutes les demandes de script (de tous les utilisateurs) plus rapidement que le navigateur de votre utilisateur moyen ne traite un seul script. Laissez-le pénétrer un instant.

Vous n’êtes pas fan de cette option ? OK, explorons la parallélisation JavaScript. L'idée de base est d'exploiter les Web Workers pour définir quels scripts seront chargés en séquence et lesquels peuvent se charger en parallèle.

Bien que vous puissiez forcer le chargement de JavaScript en parallèle, cela est extrêmement déconseillé par défaut. L’intégration d’une telle technologie atténuerait largement le besoin de RSS dans la plupart des cas.

Cependant, sa mise en œuvre sera très délicate et nécessitera (vous l'aurez deviné !) le temps d'un développeur Web senior.

La même personne que vous engagez pour effectuer votre audit complet du code JavaScript pourra également vous aider. Si vous combinez la parallélisation JavaScript avec un chemin de rendu JavaScript critique, alors vous volez vraiment.

Dans cet exemple, voici ce qui est vraiment intéressant :

Vous pouvez immédiatement voir que si le thread principal est occupé pendant 17 secondes, l'exécution de JavaScript représente 12 secondes.

Cela signifie-t-il que 12 secondes sur les 17 secondes de travail de thread sont des exécutions JavaScript ? C'est très probable.

Nous savons que tout le JavaScript est transmis par défaut via le thread principal.

C'est également ainsi que WordPress, le CMS actif, est configuré par défaut.

Étant donné que ce site exécute WordPress, toutes ces 12 secondes de temps d'exécution de JavaScript proviennent probablement des 17 secondes de travail du thread principal.

C'est une excellente idée car cela nous indique que la majeure partie du temps du thread de traitement principal est consacrée à l'exécution de JavaScript. Et vu le nombre de scripts référencés, ce n’est pas difficile à croire.

Mener la croisade vers les outils de développement Chrome

Il est temps de passer à la technique et de retirer les roues d'entraînement.

Ouvrez une nouvelle instance de Chrome. Vous devez ouvrir un profil d'invité pour vous assurer qu'il n'y a pas d'encombrement ou de plugins activés pour gonfler nos résultats.

N'oubliez pas : effectuez ces actions à partir d'un profil Chrome invité propre.

Chargez le site que vous souhaitez analyser. Dans notre cas, c'est TechCrunch.

Acceptez les cookies si nécessaire. Une fois la page chargée, ouvrez Chrome DevTools (cliquez avec le bouton droit sur une page et sélectionnez Inspecter ).

Accédez à Performances > Captures d’écran.

Appuyez sur le bouton de rechargement pour enregistrer le chargement de la page. Un rapport sera alors généré :

C’est là que nous devons tous prendre une profonde respiration et essayer de ne pas paniquer.

Ci-dessus, encadré en vert, vous pouvez voir un mince volet qui illustre les demandes au fil du temps.

Dans cette case, vous pouvez faire glisser votre souris pour sélectionner une tranche de temps, et le reste de la page et l'analyse s'adapteront automatiquement.

La région que j'ai sélectionnée manuellement est la zone recouverte d'une boîte bleue semi-transparente.

C'est là que se produit le chargement de la page principale et ce que je souhaite examiner.

Dans ce cas, j'ai approximativement sélectionné la plage de temps et d'événements entre 32 ms et 2,97 secondes. Concentrons notre regard sur l'intérieur du fil principal :

Vous savez, plus tôt, je disais que la plupart des tâches de rendu et des exécutions JavaScript sont forcées à travers le goulot d'étranglement du thread principal ?

Eh bien, nous examinons maintenant l'intérieur de ce fil conducteur au fil du temps. Et oui, en jaune, vous pouvez voir beaucoup de tâches de script.

Sur les deux premières lignes, au fur et à mesure que le temps passe, il y a de plus en plus de morceaux jaune foncé confirmant tous les scripts en cours d'exécution et le temps qu'ils mettent à être traités. Vous pouvez cliquer sur des morceaux de barre individuels pour obtenir une lecture pour chaque élément.

Bien qu'il s'agisse d'un visuel puissant, vous en trouverez un plus puissant dans la section Résumé :

Celui-ci résume toutes les données granulaires, décomposées en sections thématiques simples (par exemple, Scripting , Loading , Rendering ) via le support visuel facile à digérer d'un graphique en anneau.

Comme vous pouvez le constater, les scripts (exécution de scripts) occupent la majeure partie du chargement de la page. Ainsi, notre hypothèse antérieure à partir du mélange de données de terrain et de laboratoire de Google, qui pointait du doigt les goulots d'étranglement de l'exécution de JavaScript dans le thread principal, semble avoir été exacte.

En 2023, c’est l’un des problèmes les plus répandus, avec peu de solutions simples et disponibles dans le commerce.

Il est complexe de créer des chemins de rendu JavaScript critiques. Il faut de l'expertise pour effectuer des audits de code JavaScript, et il n'est pas si simple d'adopter la parallélisation JavaScript ou SSR.

Allons maintenant regarder l' arbre d'appels :

L’arbre d’appels est souvent plus utile que l’approche ascendante .

Les données sont similaires, mais Call Tree regroupera thématiquement les tâches dans des compartiments pratiques comme Evaluate Script (exécution de script).

Vous pouvez ensuite cliquer sur un groupe, le développer et voir les scripts et combien de temps ils ont mis à se charger. 11 % du temps a été consacré au chargement pubads_impl.jsm tandis que 6 % du temps a été consacré au chargement opus.js .

Je ne sais pas ce que sont ces modules (et vous non plus), mais c'est souvent là que commence le parcours d'optimisation.

Nous pouvons maintenant revenir sur :

• Recherchez ces scripts sur Google et voyez s'ils font partie de bibliothèques tierces, ce qu'ils font et quel est leur impact.
• Consultez le développeur pour savoir comment ceux-ci pourraient être déployés de manière plus intelligente.
• Limitez le problème aux ressources individuelles et recherchez des alternatives.
• Résolvez le déficit de performances (ou alternativement, luttez pour plus de ressources/bande passante, un environnement d’hébergement solide – si cela est effectivement nécessaire).

Autres outils de mesure et d'optimisation pour Core Web Vitals

Si vous avez réussi à rester avec moi jusqu'ici, félicitations. En termes d’analyse approfondie des Core Web Vitals et de la vitesse des pages, nous avons uniquement utilisé :

• Informations sur la vitesse de page
• Chrome DevTools (onglet Performances )

Oui, vous pouvez vraiment être aussi maigre. Cependant, il existe d’autres outils qui peuvent vous être d’une grande aide :

• GTMetrix : Particulièrement utile pour son graphique en cascade (nécessite un compte gratuit pour Waterfall), que vous pouvez apprendre à lire ici. N'oubliez pas que GTMetrix fonctionnera sans limitation par défaut, donnant des résultats trop favorables. Assurez-vous de le configurer sur une connexion LTE.
• Google Search Console : si vous configurez cela et vérifiez votre site, vous pouvez voir de nombreuses données de performances et d'utilisabilité au fil du temps, y compris les métriques Core Web Vitals sur plusieurs pages (agrégées).
• Screaming Frog SEO Spider : Ceci peut être connecté à l'API de vitesse de page, pour permettre la récupération groupée des notes Core Web Vitals Pass ou Fail (pour plusieurs pages). Si vous utilisez l'API gratuite de vitesse de page, ne la martelez pas de manière déraisonnable

Auparavant, améliorer les évaluations de vitesse de vos pages était aussi simple que compresser et télécharger quelques images.

Aujourd'hui? Il s’agit d’une croisade complexe Core Web Vitals.

Préparez-vous à vous engager pleinement. Rien de moins sera un échec.