Core Web Vitals 101 et conseils de développement

Qu'est-ce qui se passe et change ?

En mai 2021, Google a lancé le déploiement d'une mise à jour de l'algorithme de base qui ajoute un facteur supplémentaire aux signaux de classement des pages, en ce qui concerne la vitesse des pages et l'expérience utilisateur. Le déploiement de la mise à jour de base s'est étendu jusqu'en juin 2021, ce qui en fait également l'un des plus grands changements de base de l'histoire. Core Web Vitals rejoindra les anciens signaux de classement tels qu'un site sécurisé HTTPS, la convivialité mobile et les interstitiels non intrusifs en tant que signaux de recherche dans le facteur de classement global de l'expérience de la page.

Les trois composants de Core Web Vitals incluent les éléments suivants :

• Largest Contentful Paint (LCP) : mesure la vitesse de chargement perçue et marque le point dans la chronologie de chargement de la page lorsque le contenu principal de la page a probablement été chargé. Pour offrir une bonne expérience utilisateur, les sites doivent s'efforcer de faire en sorte que LCP se produise dans les 2,5 premières secondes suivant le début du chargement de la page.
• First Input Delay (FID) : mesure la réactivité et quantifie l'expérience ressentie par les utilisateurs lorsqu'ils tentent d'interagir pour la première fois avec la page. Pour offrir une bonne expérience utilisateur, les sites doivent s'efforcer d'avoir un FID inférieur à 100 millisecondes .
• Cumulative Layout Shift (CLS) : mesure la stabilité visuelle et quantifie la quantité de décalage de mise en page inattendu du contenu visible de la page. Pour offrir une bonne expérience utilisateur, les sites doivent s'efforcer d'avoir un score CLS inférieur à 0,1 .

Déclaration de version officielle de Google sur cette mise à jour de l'algorithme : https://developers.google.com/search/blog/2020/11/timing-for-page-experience

De plus, Google a publié plus d'informations sur le changement CLS tout en continuant à surveiller les performances pendant le déploiement. En conséquence, de nombreux sites ont reçu un score plus favorable en raison des récents changements et ont évité beaucoup de travail de développement pour ajuster la mise en page de leur site. Comme toujours, ces changements sont sujets à changement, nous vous recommandons donc de surveiller les CWV dans le cadre d'une liste de contrôle hebdomadaire ou mensuelle.

Que savons-nous de la mise à jour du classement ?

Comme pour la plupart des mises à jour de l'algorithme de Google, il y a beaucoup d'inconnues quant à la façon dont cela affectera le paysage de recherche actuel. Nous savons que ce sera un facteur dans le classement des pages. Cependant, nous ne savons pas quel pourcentage d'un facteur ou quel sera son impact dans l'algorithme. Un autre facteur inconnu sera si les concurrents directs s'adaptent ou prennent des mesures pour mettre à jour leur(s) site(s) pour adhérer aux nouveaux facteurs. En fonction du comportement des concurrents, cela pourrait à son tour avoir un impact positif ou négatif sur le classement de votre site, par rapport à ces pairs. Ce que nous savons, c'est que Google continuera de prioriser le classement du contenu qu'il considère comme précieux ou pertinent pour les utilisateurs par rapport aux sites Web plus rapides avec un contenu faible.

En fait, comme Google offre plus d'informations sur la mise à jour, ils ont confirmé que le contenu pertinent reste l'un des éléments les plus importants dans les classements de recherche.

"Nos systèmes continueront de prioriser les pages avec les meilleures informations dans l'ensemble, même si certains aspects de l'expérience de la page sont médiocres. Une bonne expérience de page ne remplace pas un contenu de qualité et pertinent. »

Comment se préparer à la mise à jour du classement Google Page Experience ?

En raison des facteurs inconnus liés à cette mise à jour et à la fenêtre de préavis de 6 mois de Google, le changement semble indiquer que cela deviendra un facteur de classement. Par conséquent, il est fortement recommandé que les équipes de référencement et de développement examinent les performances actuelles de Core Web Vitals de votre ou vos sites et agissent rapidement en examinant et en mettant à jour les problèmes liés à la mise à jour du signal de classement. Il est important de s'assurer que vous êtes proactif plutôt que réactif, car toute baisse de classement peut prendre un certain temps à récupérer. Nous savons tous que le référencement est un long jeu !

Comment identifier les problèmes du site, les prochaines étapes en fonction des problèmes et des conseils supplémentaires ?

Les éléments vitaux Web de base sont décrits dans le compte Google Search Console de votre site sous « Améliorations ». De plus, il y a un aspect global dans la section "Aperçu" du compte, qui ressemblera à l'exemple ci-dessous (certaines variations se produiront probablement car votre compte dépend des problèmes potentiels spécifiques à votre site). Il y a aussi une section décrite pour Desktop et Mobile. Dans cet exemple, nous examinons les problèmes liés aux mobiles.

Étant donné que tous les sites sont indexés en priorité sur les mobiles depuis septembre 2020 , nous recommandons que le temps de développement soit d'abord consacré aux problèmes mobiles. Cela dit, si votre site est réactif, il est probable que les mises à jour que vous effectuez sur Mobile auront également un impact positif sur Desktop. De plus, selon la taille du site, il peut y avoir une ménagerie de problèmes « médiocres » et « à améliorer ». Nous vous recommandons fortement de vous concentrer sur les URL "médiocres", car les éléments "nécessitant une amélioration" peuvent ne pas valoir l'effort par rapport à l'impact, ou la règle des 80/20, sur laquelle nous reviendrons plus tard !

Lors de l'examen des URL décrites dans Google Search Console qui affichent des performances moins qu'optimales, il est important de garder à l'esprit ce que John Mueller de Google a révélé sur la façon dont Google peut, dans certains cas, calculer le score Web Vitals de base comme une moyenne de plusieurs pages :

Ceci est la question:

"Lorsque cela devient un signal de classement... est-ce que ce sera au niveau de la page ou au niveau du domaine ?"

Muller a répondu

« …Ce qui se passe avec les données de terrain, c'est que nous n'avons pas de points de données pour chaque page.

Donc, pour la plupart, nous avons besoin d'avoir des sortes de regroupements de pages individuelles.

Et selon la quantité de données dont nous disposons, cela peut être un regroupement de l'ensemble du site Web (type de domaine).

… Je pense que dans le rapport sur l'expérience utilisateur de Chrome, ils utilisent l'origine qui serait le sous-domaine et le protocole là-bas.

Ce serait donc une sorte de regroupement global.

Et si nous avons plus de données pour des parties individuelles d'un site Web, nous essaierons de les utiliser.

Et je crois que c'est quelque chose que vous voyez également dans la console de recherche où nous afficherons comme une URL et disons… il y a tellement d'autres pages associées à cela. Et c'est le genre de groupement que nous utiliserions là-bas.

Vous vous demandez peut-être pourquoi nous en parlons au début de la conversation autour de Core Web Vitals ? Mueller explique que le rapport de Google Search Console décrivant les problèmes d'URL tente de catégoriser et de signaler les pages présentant les mêmes problèmes dans un groupe. Malheureusement, dans la pratique, ces regroupements d'URL ont été moins qu'utiles pour certains sites Web d'après notre expérience.

À l'occasion, nous examinerons les URL indiquées comme ayant des performances "médiocres" dans le rapport de la console de recherche Google, pour constater que les mêmes pages semblent avoir un bon état de santé lorsqu'elles sont testées avec Lighthouse et Page Speed ​​​​Insights.

En résumé, lors de l'examen des problèmes d'URL décrits dans le rapport de la console de recherche Google, nous vous recommandons de "le prendre avec un grain de sel". Notre meilleure hypothèse est que Google a l'intention de classer le score "Web Vitals" pour les pages sur la base d'un historique de 28 jours de données de navigation réelles dans le monde réel ("données de terrain" en langage Google). Cependant, ces données du monde réel sont susceptibles d'être agrégées à partir de l'ensemble du domaine (ou "origine" en langage Google) si la page ne fait pas l'objet d'un trafic important. Bien que la Search Console soit utile pour identifier le fait que vos éléments vitaux Web ont besoin d'un peu d'attention, ne vous y fiez pas pour votre audit. Veillez également à examiner les données de laboratoire (résultats individuels des pages testées en temps réel) par opposition aux données de terrain (qui peuvent concerner plusieurs pages et s'étendent toujours sur une fenêtre d'analyse de 28 jours) lors de l'exécution et de l'audit ou de la validation des correctifs.

Une fois que vous savez que vous avez un problème, si vous ne parvenez pas à déterminer la ou les pages sources, commencez par tester des pages d'exemple en laboratoire pour chacun de vos modèles de base. Par exemple, la page d'accueil, une page de produit, une page de catégorie, un article de blog, etc. Souvent, des problèmes structurels peuvent être trouvés dans chaque instance d'un type de page particulier et résolus une fois par un développeur Web via une mise à jour du modèle sous-jacent. code. Si cela ne suffit pas, envisagez une analyse similaire d'un sous-ensemble de pages individuelles en commençant par celles qui sont les plus visitées. Un outil que nous avons trouvé utile dans ce processus est l' audit de Core Web Vitals via Screaming Frog .

Conseils d'amélioration du changement de disposition cumulé (CLS)

Le changement de mise en page cumulé (CLS) mesure la somme totale de tous les scores de changement de mise en page individuels pour chaque changement de mise en page inattendu qui se produit pendant toute la durée de vie de la page. Un changement de disposition se produit chaque fois qu'un élément visible change de position d'une image rendue à la suivante.

Google recommande les conseils suivants sur la façon d'améliorer CLS pour la plupart des sites Web en respectant quelques principes directeurs :

• Incluez toujours des attributs de taille sur vos images et éléments vidéo ou réservez autrement l'espace requis avec quelque chose comme des boîtes de rapport d'aspect CSS . Cette approche garantit que le navigateur peut allouer la bonne quantité d'espace dans le document pendant le chargement de l'image. Notez que vous pouvez également utiliser la stratégie de fonctionnalité de média non dimensionné pour forcer ce comportement dans les navigateurs qui prennent en charge les stratégies de fonctionnalité.
• N'insérez jamais de contenu au-dessus du contenu existant, sauf en réponse à une interaction de l'utilisateur. Cela garantit que tous les changements de mise en page qui se produisent sont attendus.
• Préférez les animations de transformation aux animations de propriétés qui déclenchent des changements de mise en page. Animez les transitions de manière à fournir un contexte et une continuité d'un état à l'autre.

Google recommande d'utiliser le plan d'action suivant pour analyser, tester et déployer les mises à jour sur le site :

• Une fois que vous avez identifié les pages qui ont besoin de travail (décrites ci-dessus), utilisez PageSpeed ​​Insights pour diagnostiquer les problèmes de laboratoire et de terrain sur une page.
• Prêt à optimiser votre site localement en laboratoire ? Utilisez Lighthouse et Chrome DevTools pour mesurer les Core Web Vitals et obtenir des conseils pratiques sur exactement ce qu'il faut corriger. L' extension Web Vitals Chrome peut vous donner une vue en temps réel des métriques sur le bureau.
• Vous cherchez des conseils ? web.dev/measure peut mesurer votre page et vous montrer un ensemble prioritaire de guides et de codelabs pour l'optimisation, en utilisant les données PSI.
• Enfin, utilisez Lighthouse CI sur les demandes d'extraction pour vous assurer qu'il n'y a pas de régression dans Core Web Vitals avant de déployer une modification en production.

Pour en savoir plus sur la manière d'améliorer le CLS, consultez Optimiser le CLS .

Guide d'amélioration de la plus grande peinture de contenu (LCP)

La métrique LCP (Largest Contentful Paint) indique le temps de rendu de la plus grande image ou du plus grand bloc de texte visible dans la fenêtre d'affichage.

Comme actuellement spécifié dans l' API Largest Contentful Paint , les types d'éléments pris en compte pour Largest Contentful Paint sont :

• <img> éléments
• Éléments <image> à l'intérieur d'un élément <svg>
• Éléments <video> (l'image de l'affiche est utilisée)
• Un élément avec une image de fond chargée via la fonction url() (par opposition à un dégradé CSS )
• Éléments de niveau bloc contenant des nœuds de texte ou d'autres éléments de texte de niveau en ligne enfants

Google recommande les conseils suivants sur la façon d'améliorer LCP, qui est principalement affecté par quatre facteurs :

• Temps de réponse du serveur lent
• JavaScript et CSS bloquant le rendu
• Temps de chargement des ressources
• Rendu côté client

Pour en savoir plus sur l'amélioration de LCP, consultez Optimiser LCP . Pour des conseils supplémentaires sur les techniques de performance individuelles qui peuvent également améliorer le LCP, voir :

• Appliquer un chargement instantané avec le modèle PRPL
• Optimisation du chemin de rendu critique
• Optimisez votre CSS
• Optimisez vos images
• Optimiser les polices Web

Optimisez votre JavaScript (pour les sites rendus par le client)

Conclusions essentielles du développement Web à ce jour

Notre équipe de développement a constaté qu'une grande partie de la mise à jour du classement Core Web Vitals nécessitera des tests approfondis du côté du développement pour s'assurer que les mises à jour effectuées répondent aux normes établies par Google.

Dans de nombreux cas, pour les petits sites, bon nombre de ces éléments échappent au contrôle des développeurs Web. Par exemple, la vitesse du serveur est largement contrôlée par le fournisseur d'hébergement, et pour l'hébergement partagé (comme WP Engine ou Shopify), les développeurs n'auront pas le contrôle. De même, les thèmes de site prêts à l'emploi intègrent souvent Javascript et CSS qui bloquent le rendu. Dans ces cas, il peut ne pas être pratique de résoudre bon nombre des problèmes signalés. Pour ces raisons, une analyse critique est nécessaire pour déterminer l'intersection de (1) quels problèmes ont le plus d'impact et (2) quels problèmes sont causés par le code que l'équipe de développement peut et doit changer.

Après avoir commencé le processus d'examen des problèmes de Core Web Vitals chez plusieurs de nos clients, nous avons constaté qu'une grande partie de l'outil connexe fourni par Google reste immature, dans la mesure où il est capable d'identifier les problèmes (tels que les changements de charge de contenu), mais n'est pas toujours utile pour identifier la cause spécifique. Bien que nous nous attendions à ce que cela mûrisse dans les prochaines itérations de cet outil (en particulier, dans Chrome Dev Tools), nous avons constaté que des processus de diagnostic alternatifs peuvent être nécessaires pour identifier certains problèmes.

Nous avons également constaté que travailler à l'amélioration de ces mesures est de nature similaire à l'amélioration des performances de vitesse de page dans son ensemble. Dans chaque cas, nous déconseillons la poursuite du « score parfait ». Au lieu de cela, la règle 80/20 s'applique. Si vous abordez les fruits à portée de main, vous constaterez probablement une amélioration significative de vos mesures. Après cela, l'amélioration devient plus chronophage, plus coûteuse et moins impactante.

Les conseils de base tels que la suggestion de Google d'inclure un balisage préservant l'espace ou CSS sur tous les éléments d'image, de vidéo et de conteneur sont généralement de bons conseils simples à mettre en œuvre. D'autres problèmes sont plus difficiles à détecter, et à moins qu'ils n'aient un impact démesuré sur vos mesures (comme indiqué par certains des outils suggérés), il peut être préférable de mettre ces problèmes de côté.

L'architecture du site jouera également un rôle important dans la facilité relative avec laquelle ces éléments peuvent être traités. Les plateformes de sites populaires telles que Shopify et WordPress, ainsi que les constructeurs de pages graphiques tels que WP Bakery et Shogun, gèrent une partie du processus de génération HTML « en coulisses ». Les problèmes masqués par les composants du constructeur de pages (par exemple, certains chargements différés d'images) peuvent ne pas être facilement résolus sans des modifications fondamentales du site ou de la prise en charge de la plate-forme, du thème ou du fournisseur de plug-in/application.

Le concept ci-dessus s'étend aux tiers qui utilisent javascript pour charger paresseusement des widgets dans votre page (par exemple, des formulaires d'inscription intégrés à partir de plates-formes de messagerie telles que Klaviyo). Dans certains cas, placer un élément de conteneur correctement et explicitement dimensionné autour du code d'intégration du composant incriminé est une solution viable. Dans d'autres cas, le fournisseur lui-même devra peut-être apporter une modification.

Nous vous recommandons de commencer tout processus de correction avec des problèmes importants qui peuvent être résolus en modifiant les modèles de site principaux facilement accessibles (par exemple, les pages de produits, les pages de collection de produits, etc.). Cela permettra souvent à un seul changement de code d'améliorer les résultats sur des dizaines ou des centaines de pages de site. Ensuite, adressez-vous à la page d'accueil, car c'est presque toujours la page la plus visitée du site. Enfin, hiérarchisez les autres pages individuelles nécessitant une correction en fonction de la gravité du problème et de la visibilité de la page.

Comme c'est le cas avec l'amélioration de la vitesse des pages, la gestion de Core Web Vitals est importante, mais ce n'est qu'une variable parmi d'autres dans l'algorithme de classement de Google, et le référencement doit également être équilibré par rapport aux autres priorités du site et de l'entreprise en concurrence pour le temps et le budget.