Catégorie : Google Page Experience

Les récents Core Algorithm Updates étaient-ils liés à la vitesse de la page ?

John Mueller de chez explique comment les changements de classement peuvent être attribués à la vitesse de chargement de la page, mais les Core Algorithm Updates étaient des choses distinctes.

Les récents Core Algorithm Updates étaient-ils liés à la vitesse de la page ?

On a demandé à John Mueller de chez Google si les Core Algorithm Updates de Juin et Juillet 2021 étaient plus liés à la vitesse de chargement de la page.

John Mueller a donné un aperçu des Core Updates, puis a noté comment les choses peuvent être liées à la vitesse de la page.

Plusieurs mises à jour de Google en Juin et Juillet 2021

 

Le June Core Algorithm Update (mise à jour du coeur de l’algorithme de Juin) a été déployé en Juin 2021. Mais il y avait aussi un Page Experience Update (mise à jour de l’expérience de la page) qui a été publiée, ainsi qu’un June 2021 Spam Algorithm Update (mise à jour de l’algorithme de spam).

L’attribution de fluctuations de classement à des modifications ou à des liens spécifiques du site Web lors d’un core algorithm update peut être sommaire, car certaines baisses de ranking peuvent ne rien à voir avec les modifications du site Web et être totalement fortuites.

Toute fluctuation de ranking en Juin 2021 sera encore plus difficile à attribuer à un seul type de changement de site Web, étant donné le nombre de modifications apportées à l’algorithme ce mois-là.

Les Core Algorithm Updates étaient-ils liés à la vitesse de la page ?

 

La personne qui posait la question semblait chercher une confirmation des observations selon lesquelles de nombreuses personnes avaient cette vitesse de chargement de la page semblait être une qualité courante dans les sites qui ont obtenu des classements lors des Core Algorithm Updates de Juin et Juillet 2021.

La question posée :

J’ai lu en ligne que les gens ont dit qu’ils avaient vu une amélioration après le Core Algorithm Update de Juin.

Ils en ont également vu un pour Juillet dernier.

Pour nous, ce n’était pas la même chose. Qu’est-ce qui aurait pu revenir en Juillet ? Est-ce que cela pourrait être lié à la vitesse ?

 

Les mises à jour de la vitesse et du Core Algorithm étaient distinctes

 

John Mueller a d’abord noté comment la vitesse de la page et les mises à jour du coeur de l’algorithme étaient séparées.

John Mueller a répondu :

La vitesse… Pour autant que je sache, il s’agissait essentiellement d’updates distincts et uniques que nous avons faits.

Nous les appelons à la fois des Core Updates parce qu’ils affectent le cœur de nos systèmes de ranking.

Mais cela ne signifie pas qu’ils affectent les mêmes parties essentielles du système de classement.

Donc, de ce point de vue-là, ce n’est pas le cas que si vous voyez un changement… au cours de l’une de ces mises à jour, vous verrez toujours un changement pendant l’autre.

Donc, à partir de là, je ne suppose pas qu’ils doivent être liés.

 

La vitesse de la page pourrait-elle affecter les changements de classement en juin et juillet 2021 ?

 

John Mueller a ensuite affirmé que la vitesse de la page pourrait être une raison pour certains changements de classement.

John Mueller a expliqué le lien entre les changements de classement et la vitesse de la page :

… Est-ce que cela pourrait être lié à la vitesse ?

Les choses peuvent certainement être liées à la vitesse de la page parce que toute la Page Experience Update est quelque chose qui, je pense, a commencé à se déployer en Juin.

Donc, en Juillet 2021, vous pourriez encore voir quelques changements.

Mais le lui-même n’est pas quelque chose qui, je pense, est lié au Page Experience Update.

C’est un peu une chose distincte.

Étant donné que Google a publié plusieurs updates en juin et juillet 2021, il peut être difficile d’isoler des modifications spécifiques et d’attribuer des fluctuations de classement au Core Algorithm Update.

Source : Searchenginejournal

Google modifie les critères de classement de Page Experience

Le rapport Expérience sur la page‎ dans Search Console reçoit une mise à jour qui facilite la navigation.

Google modifie les critères de classement de Page Experience

Google supprime la navigation sécurisée des critères que les sites doivent respecter pour bénéficier du facteur de classement de Page Experience.

À la suite de cette modification, Google met à jour le rapport “Expérience sur la page” de la Search Console avec une conception simplifiée qui supprime les données redondantes.

Plus précisément, la navigation sécurisée () et d’expérience publicitaire sont supprimés du rapport. Google explique la raison d’être de cette décision dans un billet de blog.

En outre, plusieurs correctifs sont implémentés pour améliorer la façon dont les données manquantes sont traitées.

Voici plus de détails sur tous les changements déployés aujourd’hui.

Suppression du panneau de navigation sécurisée (https)

Google supprime le widget de navigation sécurisée du rapport Expérience sur la page car il ne s’agit plus d’un signal de classement.

Le rapport a été créé pour aider les référenceurs à comprendre comment les sites se comportent par rapport aux signaux qui composent le facteur de classement de l’expérience de la page.

Google supprime le widget de navigation sécurisée du rapport Expérience sur la page car il ne s’agit plus d’un signal de classement.

L’inclusion de données de navigation sécurisée dans le rapport n’est pas nécessaire car elles ne sont pas utilisées dans les classements.

Les systèmes de navigation sécurisée chez Google sont conçus pour assurer la sécurité des utilisateurs sur Internet. Parfois, les sites sont victimes de détournements de tiers, ce qui peut provoquer que des avertissements de navigation sécurisée s’affichent.

Nous reconnaissons que ces problèmes ne sont pas toujours sous le contrôle des propriétaires de sites, c’est pourquoi nous précisons que la navigation sécurisée n’est pas utilisée comme signal de classement et ne figurera pas dans le rapport Expérience sur la page.

Console continuera à signaler les indicateurs de navigation sécurisée en dehors du rapport Expérience sur la page dans .

Suppression du widget Expérience publicitaire

Google supprime le widget Expérience publicitaire de la Search Console pour éviter de faire apparaître les mêmes informations dans plusieurs rapports.

Une version autonome du rapport d’expérience publicitaire restera disponible dans la Search Console, qui identifie les expériences publicitaires qui enfreignent les normes “Better Ads” ou “Meilleures Publicités”.

“Semblable à la navigation sécurisée, le rapport Expérience publicitaire n’est pas un facteur pour le signal de classement de Page Experience.”

 

Améliorations supplémentaires

Google met à jour le rapport Expérience sur la page avec plusieurs corrections de bugs et améliorations, notamment :

  • Ajout d’une bannière « Aucune donnée récente » au rapport Core Web Vitals et au rapport Expérience sur la page.
  • Correction d’un bug qui provoquait l’affichage du rapport « HTTPS défaillant » lorsque les données étaient manquantes.
  • Reformulation du texte d’état vide dans le rapport Expérience sur la page et le rapport Signaux web essentiels.

Pour rappel, la mise à jour de l’algorithme Google Page Experience a commencé à être déployée le 15 juin 2021 et le déploiement sera terminé d’ici le 31 août 2021.

4 façons d’optimiser pour Google Page Experience Update

Il n’est pas trop tard pour se préparer à la mise à jour de Google Page Experience ou encore de l’améliorer alors même qu’elle est en cours de déploiement.

4 façons d’optimiser pour Google Page Experience Update

 

Découvrez comment obtenir un avantage concurrentiel dans Search.

Si vous n’avez toujours pas réussi à optimiser les métriques Page Experience et que vos concurrents l’ont fait, vous constaterez peut-être qu’ils bénéficient d’un boost de classement que vous manquez.

Dans cet article, vous découvrirez trois domaines prioritaires clés qui vous aideront à vous améliorer pour Page Experience Update, ainsi que découvrir plusieurs autres problèmes à avoir sur votre liste de tâches.

1. Travaillez sur votre vitesse de chargement

Le premier des Core Web Vitals de Google est “Largest Contentful Paint” (LCP), qui fait référence au contenu le plus grand et le plus important d’une page Web.

Cette métrique déterminera la rapidité avec laquelle votre page restitue son contenu le plus important, afin que les utilisateurs puissent le voir.

Il existe un certain nombre de façons d’optimiser pour LCP.

Une chose que vous pouvez faire est d’optimiser votre serveur, car des temps de réponse lents peuvent parfois être liés à des serveurs lents.

L’accélération d’un serveur peut impliquer l’exécution de conseils de performances afin que le serveur affiche une page statique lorsqu’elle est demandée plutôt que de créer la page chaque fois que quelqu’un clique dessus.

D’autres composants de page Web qui peuvent ralentir le chargement LCP incluent des images, des vidéos et des éléments au niveau des blocs avec des fonctionnalités de texte.

Si ces éléments sur vos pages sont au-dessus de la ligne de flottaison, plus leur chargement est lent, plus votre LCP est lent.

Pour résoudre ces problèmes, vous devrez compresser vos images et fichiers texte, mettre en cache certaines ressources et précharger certains de vos éléments.

2. Travaillez sur votre interactivité

Le deuxième Core Web Vital est First Input Delay (FID). C’est le temps qu’il faut aux utilisateurs pour pouvoir interagir avec un élément sur lequel ils ont cliqué, tel qu’un lien ou un bouton.

Aux yeux de Google, votre FID devrait viser à être inférieur à 100 millisecondes. Mais parlons de ce que cela signifie.

Les lecteurs sont sans aucun doute familiers avec les pages Web qui les font attendre indéfiniment après avoir cliqué sur un élément pour accéder à une nouvelle page, modifier un panier d’achat, etc.

Eh bien, ce n’est pas bon pour les utilisateurs. Mais pourquoi cela se produit-il ?

C’est principalement parce que le navigateur est trop occupé par d’autres tâches, telles que l’analyse et l’exécution d’un fichier JavaScript lourd.

Maintenant, nous voulons nous concentrer principalement sur les premières interactions des utilisateurs avec une page Web, c’est-à-dire le temps nécessaire au chargement.

Tout comme pour rencontrer quelqu’un de nouveau, les premières impressions comptent. Si les utilisateurs savent dès le départ que votre site est plus lent qu’un escargot, ils partiront probablement et ne reviendront pas.

Mais une forte première impression – comme dans une page qui se charge rapidement – ira sur le long terme vers l’augmentation des engagements des utilisateurs avec cette page dans son ensemble.

C’est pourquoi FID est une mesure si importante. Comment y remédier ? Cela dépendra de votre site Web spécifique.

Utilisez des outils tels que PageSpeed Insights pour voir comment vous allez et où vous pouvez vous améliorer.

Vous voudrez peut-être vous pencher sur la division des tâches longues, la réduction de JavaScript et la hiérarchisation du chargement des scripts afin que les éléments les plus importants soient en premier disponibles pour les utilisateurs.

3. Travaillez sur votre Layout Shift (décalage de mise en page)

Enfin, nous avons le troisième Core Web Vital, le Cumulative Layout Shift (CLS). Il s’agit d’une mesure de la quantité de déplacement de la mise en page du contenu de votre page pendant le chargement de la page.

Vous avez probablement rencontré ce problème, aussi.

Vous attendez qu’une page se charge complètement et vous cliquez sur quelque chose pour constater qu’un autre élément a chargé sur la page et a donc poussé l’élément souhaité dans une autre direction.

En conséquence, vous avez cliqué sur quelque chose que vous ne vouliez pas, comme une annonce ou même un bouton « Soumettre la commande ».

Cela fait une mauvaise expérience utilisateur, et c’est pourquoi CLS est suffisamment important pour être considéré comme un élément principal de l’expérience de page ou Page Experience.

Comment pouvez-vous résoudre ce problème afin de profiter des classements que les peuvent fournir ?

Vous avez besoin d’un score CLS de 0,1 pour « passer » le test de Google. C’est le maximum que Google veut voir.

Aussi plus élevé, et vos pages Web sont susceptibles de changer un peu. Google considère qu’un score de 0,25 est médiocre.

Si vous utilisez un site , vous remarquerez probablement que les éléments suivants sont à l’origine de votre CLS :

  • Images et vidéos sans dimension.
  • Annonces sans dimension et autres objets intégrés.
  • Animations et autres contenus dynamiques.
  • Flashs de texte non stylé.

La correction de CLS s’applique principalement aux mobiles, car Google donne la priorité au mobile-first, mais aussi parce que les appareils mobiles ont des processeurs plus faibles et des ports d’affichage plus petits.

Que devrez-vous faire pour éliminer cette mise en page (layout) ? Cela dépend de ce qui en est la cause, mais si nous prenons 2 exemples ci-dessus :

  • Les navigateurs ne sauront pas comment espacer les images et les vidéos sans dimensions, ce qui signifie que les zones où elles seront éventuellement changeront probablement au fur et à mesure du chargement d’une page.Vous pouvez verrouiller cela en ajoutant des dimensions spécifiques à vos images et vidéos.
  • Ensuite, en ce qui concerne les flashs de texte non stylé, vous devrez précharger vos polices.Cela indique aux navigateurs de charger vos polices en tant qu’élément prioritaire – dans la première peinture significative (First Paint). Dans ce cas, vous n’aurez pas de modifications de police discordantes qui entraîneront des cumulative layout shifts ou changements de disposition cumulatifs.

    4. Autres éléments de Page Experience à garder à l’esprit

    Bien sûr, les Core Web Vitals ne sont pas les seules choses que vous devez étudier pour optimiser votre site pour la mise à jour de l’expérience de page.

    Prenez la compatibilité mobile.

    Google jugera désormais chaque site par sa compatibilité mobile, en particulier en ce qui concerne des problèmes tels que les petites tailles de texte et l’utilisation des médias Flash, que les appareils mobiles d’aujourd’hui ont tendance à ne pas prendre en charge.

    Il y a aussi la question du rapport Expérience sur la page dans Console.

    Il s’agit d’une ventilation des performances de votre site pour Google Page Experience Update, mais qu’en est-il de tous ces propriétaires de sites disant qu’ils ne voient aucune donnée ?

    Google a confirmé qu’un rapport vide signifie simplement qu’il n’y a pas assez de données concluantes pour dire dans un sens ou dans l’autre comment votre site fonctionne.

    Même si vous avez un trafic décent, la réponse est probablement que vous avez juste besoin de plus de trafic – et pour que ce trafic génère des données pertinentes – si vous voulez que le rapport soit rempli.

    Google veut voir une bonne expérience utilisateur non seulement dans le contenu organique, mais aussi avec la publicité.

    Vérifiez et assurez-vous que les annonces sur votre site ne sont pas interruptives ou distrayantes.

    Et n’oubliez pas que votre site doit être sécurisé () si vous voulez bien faire par la mise à jour de l’expérience de page.

    HTTP non sécurisé n’est plus conseillé. Les utilisateurs doivent savoir que leurs données sont sécurisées avec vous sur votre site – et Google doit également le savoir.

    La Page Experience Update a été lancé en deux temps

    Il y a beaucoup à gérer en ce qui concerne vos Signaux Web Essentiels ou Core Web Vitals et votre Expérience de page, mais en fin de compte, il s’agit de fournir la meilleure expérience utilisateur possible.

    Si vous n’avez pas encore prévu de temps pour vérifier et optimiser ces éléments, vous voudrez le faire dès que possible.

    Mais pas de panique. Vous ne serez pas pénalisés algorithmiquement pour ne pas vous être encore alignés sur tous les Core Web Vitals et les éléments d’expérience de page.

    Cette mise à jour est une sorte de bris d’égalité, selon Google. Si toutes les autres choses sont considérées comme égales, offrir une meilleure expérience telle que déterminée par les métriques ci-dessus pourrait vous donner l’avantage.

    Et si vous voyez les classements chuter, ce n’est pas parce que vous êtes punis. Il se peut que vos concurrents directs donnent la priorité à ces optimisations et que vous, vous ne le faîtes pas.

    C’est une incitation à bouger !

    Source : Searchenginejournal

La mise à jour de Google Page Experience est déployée

confirme que sa mise à jour tant attendue de l’expérience de page ou Page Experience a commencé à se déployer.

La mise à jour de Google Page Experience est déployée

 

La mise à jour de l’algorithme commence à être déployée maintenant et sera terminée d’ici la fin du mois d’août 2021.

La mise à jour sera lentement déployée à tous les utilisateurs du monde entier. Les Top Stories ou “A la une” commenceront à utiliser le signal d’ici ce jeudi.

Dans une annonce, Google déclare :

à partir de la mi-juin 2021.

Page Experience Update se déploie progressivement (Top Stories commencera à utiliser ce nouveau signal d’ici jeudi). Il sera terminé d’ici la fin du mois d’août 2021.

Depuis longtemps annoncé, puis reporté, le moment est donc enfin venu : Google a commencé à déployer la Page Experience Update (qui comprend également Core Web Vitals).

Cependant, très peu de choses changeront à court terme et les effets à long terme seront gérables.

D’une part, Google prendra du temps de mi-juin à fin août pour déployer la mise à jour : deux mois et demi complets est un nouveau record pour une mise à jour annoncée par Google. Cela signifie que les changements de classement à court terme (s’ils existent) ne seront que très mineurs.

Les sites ne doivent donc pas s’attendre à voir des changements drastiques à la suite de cet Update, dit Google, et toute baisse ou pic soudain devrait être atténué par le processus de déploiement progressif.

Pour récapituler ce qui a déjà été partagé avec les propriétaires de sites et la communauté , voici en quoi consiste la mise à jour de l’Expérience de Page.

 

Qu’est-ce que Page Experience Update ?

 

La mise à jour de l’expérience de page prend en compte plusieurs signaux qui entrent dans la création d’une expérience de navigation optimale pour les utilisateurs.

Google évalue chacun des signaux et donne à un site Web un score global d’expérience de page. Les propriétaires de sites peuvent afficher leur score dans le nouveau rapport “Expérience sur la page” dans la Search Console.

Ce sont chacun des signaux et ce qui est nécessaire pour obtenir un « bon » score d’expérience de page.

  • : Consultez notre post pour améliorer les Core Web Vitals de Google.
  • Facilité d’utilisation mobile : une page ne doit comporter aucune erreur d’utilisation mobile.
  • Problèmes de sécurité : tout problème de sécurité pour un site disqualifie toutes les pages du site d’un bon état.
  • Utilisation de HTTPS : une page doit être servie via HTTPS pour être éligible au statut d’expérience de bonne page.
  • Expérience publicitaire : Un site ne doit pas utiliser de techniques publicitaires qui sont distrayantes, qui interrompent le lecteur ou autrement ne sont pas propices à une bonne expérience utilisateur.

Dans le cadre de cette mise à jour, n’est plus une exigence pour les pages pour se classer dans le carrousel Top Stories. Ce changement prendra effet dès ce jeudi.

En outre, Google étend l’utilisation du contenu non AMP à et supprime l’icône du badge AMP des résultats de recherche.

Source : Searchenginejournal

Google Page Experience s’appliquera aussi aux résultats sur desktop

Le prochain Google Page Experience Update  s’appliquera à la fois aux résultats de recherche de bureau et aux résultats sur mobile.

Google Page Experience s’appliquera aussi aux résultats de recherche sur desktop

indique que la prochaine mise à jour Page Experience, qui a été pensée pour avoir seulement un impact sur la recherche mobile, s’appliquera aux résultats de recherche de bureau aussi.

Ces informations ont été révélées lors d’une session sur la préparation de la mise à jour de Page Experience lors de Google I / O le mardi dernier. Voici le Tweet d’annonce :

L’expérience de page ou Page Experience est importante sur tous les types de surfaces.

Alors que nous commençons avec le mobile à la mi-Juin, le ranking de page expérience est à venir sur le bureau aussi !

Depuis que Google a annoncé en Novembre dernier

Les plans ont changé et la mise à jour est maintenant sur son chemin vers l’ordinateur. Jeffrey Jose, chef de produit chez , déclare :

Aujourd’hui, je suis heureux d’annoncer que nous apportons le classement de Page Experience sur le bureau.

C’est pourquoi nous travaillons dur pour apporter le classement de l’expérience de page au desktop. Comme toujours, nous fournirons des conseils, de la documentation et des outils mis à jour en cours de route pour aider vos pages à donner le meilleur d’elles-même. Restez à l’écoute pour plus de détails à ce sujet.

Le phrasé donne l’impression qu’il y aura un ensemble distinct de critères pour la mise à jour de Page Experience sur mobile et sur ordinateur.

Cela aurait du sens compte tenu des différentes attentes des utilisateurs lors de la visite d’une page de bureau par rapport au mobile. Sans parler de la différence dans la façon dont les pages Web sont chargées sur un ordinateur de bureau par rapport à un smartphone.

Le Update pour mobile est actuellement prévu pour être déployé à la mi-Juin 2021.

On ne sait pas si la mise à jour de desktop sera lancée en même temps.

Comme indiqué par Jose, Google fournira d’autres documents et des conseils avant la mise à jour en ligne.

Rappelons qu’initialement, Google nous avait dit que Page Experience sera lancée pour les pages mobiles seulement et les pages de bureau ne seraient pas prises en compte, mais cela va maintenant changer à l’avenir.

Maintenant que vous avez vos pages mobiles prêtes pour cette mise à jour, vous pouvez déplacer l’accent vers vos pages de bureau.

Source : Searchenginejournal

96% des sites ne passent pas les 3 signaux Core Web Vitals

À l’approche du lancement de l’algorithme Google Page Experience Update, cette étude de Searchmetrics révèle comment les sites Web fonctionnent par rapport aux points de repère de Google.

96% des sites ne passent pas les 3 signaux Core Web Vitals

 

Une grande expérience utilisateur est au cœur de Google Update et les nouvelles mesures pourraient avoir un impact significatif sur votre classement !

Dans l’étude approfondie de Searchmetrics.com, il a été découvert que seuls 4% des sites Web ont obtenu un bon score dans tous les 3 signaux Core Web Vitals.

96 % n’ont pas réussi à passer l\’ensemble des 3 signaux.

Vous ne pouvez donc pas ignorer l’impact futur que Core Web Vitals pourrait avoir sur votre site Web.

Découvrez les gagnants et les perdants actuels, comment Searchmetrics.com a évalué leurs scores et utilisé ces informations pour réduire le risque que les Core Web Vitals affectent le rendement de votre entreprise.

La communauté s’apprête à accueillir la prochaine mise à jour de Core Web Vitals, qui devrait être lancé à la mi-Juin 2021.

Ce nouvel algorithme Google met l’accent sur l’expérience utilisateur.

Trois mesures de Core Web Vitals (CVW) – Largest Contentful Paint, First Input Delay et Cumulative Layout Shift – évalueront les éléments critiques de l’expérience utilisateur, y compris la stabilité visuelle, l’expérience de chargement de la page et l’interactivité.

Cette performance sera ensuite utilisée comme signal de classement et devrait affecter le classement des pages.

Mais pour beaucoup, cette mise à jour soulève plus de questions que de réponses :

  • Dois-je changer quelque chose sur mon site web pour me préparer à cette mise à jour ? Si oui, quoi ?
  • Google va-t-il immédiatement déclasser les classements des sites web ayant de mauvais scores CWV ?
  • Dans quelle mesure les sites Web concurrents sont-ils performants en termes de CWV ? Quels repères dois-je viser ?
  • D’autres facteurs de classement sont-ils interconnectés avec mon score Core Web Vitals ?
  • Dans quelle mesure est-il facile d’optimiser les sites Web créés avec des plateformes builder/CMS telles que ou Wix ?
  • Les entités de Google (p. ex., ) obtiennent-elles de bon résultats dans Core Web Vitals ?

Searchmetrics a donc voulu dans son étude approfondir et trouver des réponses axées sur les données à ces questions.

Il a donc analysé plus de 2 millions d’URL à travers les Core Web Vitals et d’autres mesures pour comprendre :

  • La performance des sites Web.
  • Si les repères de Google sont réalistes et utiles pour les entreprises.

Mais avant de plonger dans les données, nous allons comprendre ce que sont les Core Web Vitals et, plus important encore, la logique derrière eux.

 

Qu’est-ce que Core Web Vitals & ses Benchmarks ?

 

Il existe trois paramètres Core Web Vitals :

Qu’est-ce que Core Web Vitals & ses Benchmarks ?

 

  • Largest Contentful Paint (LCP) mesure le temps de rendu du plus grand bloc d’image ou de texte visible dans le viewport.L’idée clé est de fournir une mesure simple qui montre la rapidité avec laquelle le contenu principal d’une page se charge.

    Pour fournir une bonne expérience utilisateur, LCP doit se produire dans les 2,5 secondes qui sont après le début du chargement de la page.

  • First Input Delay (FID) mesure quand un utilisateur interagit pour la première fois avec la page.Pour fournir une bonne expérience utilisateur, les pages doivent avoir un FID de moins de 100 millisecondes.
  • Cumulative Layout Shift (CLS) est un score qui mesure la quantité de changements du contenu pendant le rendu des pages.Beaucoup de changement de contenu crée une expérience utilisateur négative.

    Pour offrir une bonne expérience utilisateur, les pages doivent maintenir un CLS inférieur à 0,1.

Il existe trois paramètres Core Web Vitals

Qu’est-ce que Google essaie d’accomplir avec Core Web Vitals ?

 

D’après Google, cette mise à jour a 2 objectifs principaux :

  • Pour accroître l’accent mis par Google sur l’expérience utilisateur. En termes simples, si un utilisateur a une bonne expérience sur une page Web, Google devrait classer cette page plus haut.
  • Faciliter la conception des performances du site Web par les marques et les entreprises et améliorer l’expérience utilisateur.

Pourquoi maintenant ?

Nous vivons dans un monde où les utilisateurs veulent profiter d’un contenu de haute qualité aussi bien que possible sur tous les appareils. Mais les sites Web le fournissent-ils ?

Nous savons tous combien il est frustrant de rechercher rapidement un article de news pour constater que la page prend une éternité pour se charger.

Lorsque vous arrivez enfin sur la page et faites défiler ou cliquez sur quelque chose alors que la page bouge ou change, comme une bannière publicitaire qui tente de vous vendre quelque chose.

Ce qui n\’est pas vraiment idéal.

Google Core Web Vitals Update est à bien des égards une réponse aux sites Web qui ne sont pas à la hauteur des attentes des utilisateurs. C’est un message clair que ne pas donner la priorité aux utilisateurs peut avoir un effet négatif sur votre ranking.

 

Qu’est-ce qui cause de mauvaises performances web?

 

De nombreux facteurs sont à l’origine de mauvaises performances web.

À bien des égards, les temps de chargement lents sont un symptôme de ce qui est devenu une pratique courante pour la création d’un site Web.

 

Les plates-formes de création de sites Web

 

Plutôt que de créer quelque chose sur mesure, les entreprises se tournent de plus en plus vers les créateurs de sites Web tels que Squarespace ou Wix pour gagner du temps.

Le problème est que ces constructeurs de sites Web sont faciles à utiliser sur la surface, ils peuvent être difficiles à optimiser sous le capot.

Souvent, les pages Web conçues à l’aide de ces modèles chargent tous les scripts, feuilles de style et blocs de code même s’ils ne sont pas nécessaires.

Cela peut provoquer ce qu’on appelle un ballonnement de code – lorsque du code inutile est chargé sur une page Web, ce qui entraîne des temps de chargement de page lents.

 

Économie Web centrée sur le plugin

 

La logique d’une plate-forme comme WordPress est également centrée sur le plugin.

Cela signifie que si vous avez besoin de faire quelque chose au-delà de l’ajout de contenu de base, comme l’ des images ou le lazy loading sous la ligne de flottaison, alors vous aurez besoin d’utiliser un plugin.

Ces plugins sont des solutions rapides, mais sont une autre source de ballonnement de code.

 

Les chiffres de l’étude de Searchmetrics

 

L’étude de Searchmetrics sur Google Core Web Vitals a révélé que moins de 4% des sites Web américains qui ont été analysés obtiennent un score « Bon » dans tous les 3 Core Web Vitals.

Les chiffres de l’étude de Searchmetrics

 

Bien que les sites se classant dans le top 5 des positions de recherche Google ont légèrement mieux performé que ceux en dehors de ce top 5, ils avaient toujours les mêmes problèmes de performances globales.

 

Bien que les sites se classant dans le top 5 des positions de recherche Google ont légèrement mieux performé que ceux en dehors de ce top 5, ils avaient toujours les mêmes problèmes de performances globales.

Les sites Web manquent de stabilité visuelle

 

La plus grande pierre d’achoppement a été la stabilité visuelle, mesurée par le Cumulative Layout Shift. Peu de sites Web ont obtenu un score \ »Bon\ » dans cette mesure.

Searchmetrics dit avoir trouvé que le score moyen du CLS du Top 20 se situe à 0,38, bien au-dessus du bon seuil de Google qui est de 0,1 et même en dehors du seuil modéré de 0,25.

Cela s’explique par l’augmentation du contenu dynamique tels que les emplacements publicitaires, les boîtes d’abonnement aux newsletters et les sites Web ne réservant pas d’espace dans la mise en page pour ces éléments.

Le ballonnement du code est réel

 

Compte tenu du nombre de sites Web créés par des plates-formes telles que Squarespace et Wix, les données de Searchmetrics confirment que le ballonnement du code (Bloat code) est un véritable problème.

En moyenne, les 20 principaux sites Web américains sur pourraient économiser environ 1 seconde en temps de chargement de page simplement en supprimant le JavaScript inutilisé.

 

Les images et vidéos sont encore mal optimisées

 

L’une des principales causes de la lenteur de la vitesse de chargement était les fichiers d’actifs volumineux tels que les images et les vidéos.

Les sites Web devraient viser à reporter le chargement de tout actif en bas de la ligne de flottaison et se concentrer uniquement sur ce qui est nécessaire.

L’utilisation de formats de nouvelle génération comme le WebP de Google peut également entraîner une réduction substantielle de la taille de l’actif.

 

Qu’en est-il de YouTube ?

 

Searchmetrics a également filtré YouTube des résultats.

Fait intéressant, il a remarqué une amélioration significative des mesures liées à la vitesse de chargement.

Cela signifie que YouTube fonctionne mal dans des mesures telles que Largest Contentful Paint.

En tant que site web lourd d’actifs, il faut s’y attendre, cependant, YouTube parvient à surmonter cela et se classe toujours haut.

 

Les benchmarks de Core Web Vitals de Google sont-ils réalistes ?

 

Searchmetrics a analysé les performances des Core Web Vitals pour le bureau et le mobile et il estime que – peut-être étonnamment – les valeurs de l\’ordinateur fournissent une meilleure référence à viser.

Mais pourquoi est-ce que c’est comme ça ?

Google étrangle les données pour émuler un appareil mobile de milieu de gamme lors de l’analyse des performances mobiles.

Toutefois, cela conduit à des temps lents qui ne reflètent pas nécessairement l’état actuel du web mobile.

Alors est-il juste de punir les sites Web pour les mauvais scores Core Web Vitals ?

Les efforts déployés par Google pour rendre les mesures de l’expérience utilisateur plus transparentes pourraient aider les entreprises à améliorer objectivement leurs sites pendant leur développement.

Plutôt que de demander des fonctionnalités et des éléments de conception, les entreprises pourraient informer les cibles Core Web Vitals que les développeurs web doivent atteindre.

Cependant, c’est plus difficile à imaginer pour les créateurs web “out-of-the-box” comme Wix et WordPress.

Ils comptent souvent sur le chargement de nombreux éléments de mise en page dynamique et l’utilisation de plugins JavaScript pour accomplir des tâches relativement basiques.

Pour rester compétitives, ces plates-formes CMS devront améliorer leur jeu en aidant les sites Web à atteindre les objectifs d’expérience utilisateur et en offrant des moyens transparents pour optimiser les performances du site Web.

 

Core Web Vitals affectera-t-il les classements en Juin 2021 ?

 

C’est la question à 1 million de dollars.

Avec tant de sites Web qui fonctionnent mal dans les Core Web Vitals, il semble peu probable que Google punissent les entreprises dans l’ensemble.

Toutefois, l’analyse complète de Searchmetrics devrait servir de rappel que l’expérience utilisateur n’est actuellement pas assez bonne sur la plupart des sites Web.

S’attaquer à ce problème maintenant, ainsi que les meilleures pratiques de développement web qui placent l’utilisateur au centre de la scène, sera bénéfique à long terme.

Il est difficile de prédire exactement combien Google utilisera les scores Core Web Vitals pour déterminer les classements, mais il est certain que les sites Web avec d’excellentes expériences utilisateur auront un avantage concurrentiel crucial.

Une bonne expérience utilisateur envoie de bons signaux d’utilisateur à Google qui vont favoriser ou booster les classements.

Source : Searchenginejournal

Google lance un rapport Expérience sur la page dans la Search Console

La mise à jour de l’expérience de page ou Page Experience sera maintenant progressivement mise en œuvre à partir de la mi-Juin 2021 et ne sera pas entièrement en ligne avant la fin du mois d’Août.

Google lance un rapport Expérience sur la page après le report de Page Experience

 

L’année dernière, Google avait annoncé que Search utiliserait la vitesse de chargement des pages et d’autres mesures qui reflètent mieux la façon dont les utilisateurs vivent le Web pour classer les résultats en 2021. a fourni aujourd’hui plus de détails et une chronologie sur la prochaine « Page Experience Update ».

Google repousse ainsi le calendrier de déploiement de cette mise à jour pour « vous aider à continuer à apporter des améliorations à votre site Web avec Page Experience e à l’esprit », a déclaré la société.

 

Déploiement de Page Experience à la mi-Juin 2021

 

Google a déclaré dans son post d’annonce :

Nous commencerons à utiliser Page Experience dans le cadre de nos systèmes de classement à partir de la mi-Juin 2021. Toutefois, Page Experience ne jouera pas pleinement son rôle dans le cadre de ces systèmes avant la fin du mois d’août.

Vous pouvez y penser comme si vous ajoutiez un arôme à un aliment que vous préparez. Plutôt que d’ajouter la saveur tout à la fois dans le mélange, nous allons lentement l’ajouter tout au long de cette période de temps.

Comme nous l’avons déjà dit, alors que cette mise à jour est conçue pour mettre en évidence les pages qui offrent de grandes expériences utilisateur, l’expérience de page reste l’un des nombreux facteurs dont nos systèmes prennent en compte.

Dans ce contexte, les sites ne devraient généralement pas s’attendre à des changements radicaux. De plus, comme nous faisons cela graduellement, nous serons en mesure de surveiller tout problème imprévu ou non-intentionnel.

Le changement de classement pour la mise à jour de l’expérience de page commencera à la mi-Juin et sera un déploiement « graduel ».

Le déploiement sera terminé plusieurs semaines plus tard d’ici la fin du mois d’Août. Le retard signifie que Google « sera en mesure de surveiller tous les problèmes inattendus ou involontaires. »

Cette nouvelle façon va évaluer les facteurs de vitesse (temps de chargement), de réactivité (interactivité), et la stabilité visuelle des sites Web.

Google affirme que ces Core Web Vitals fournissent une « image holistique de la qualité de l’expérience d’un utilisateur sur une page Web », en particulier sur mobile.

 

Détails sur ce qui sera inclus dans la mise à jour

 

La mise à jour de Page Experience examinera plusieurs signaux d’expérience de page, y compris les trois paramètres : LCP, FID et CLS (en tenant compte du fait que Google a récemment amélioré CLS).

En outre, la fonction carrousel Top Stories sur sera mise à jour pour inclure tout le contenu des news, à condition qu’il réponde aux politiques de . Cela signifie que l’utilisation du format n’est plus nécessaire et qu’aucune page, indépendamment de son score Core Web Vitals ou de son statut d’expérience de page, sera éligible pour apparaître dans le carrousel Top Stories.

Google précise dans son post :

Nous apportons également des mises à jour similaires à l’application Google Actualités, une destination clé pour les utilisateurs du monde entier afin d’avoir une vue d’ensemble des news importantes de la journée.

Dans le cadre de Page Experience Update, nous élargissons l’utilisation du contenu non AMP pour alimenter l’expérience de base sur news.google.com et dans les applications mobiles Google Actualités.

En outre, nous n’afficherons plus l’icône badge AMP pour indiquer le contenu AMP. Vous pouvez vous attendre à ce que ce changement arrive à nos produits pendant que la mise à jour de l’expérience de page commence à se déployer à la mi-Juin.

Nous continuerons à tester d’autres façons d’identifier le contenu avec une grande expérience de page, et nous vous tiendrons au courant lorsqu’il y aura plus à partager.

Si vous êtes à la recherche de plus de détails, jetez un oeil à la page de Questions-réponses de Google sur Core Web Vitals & Page Experience.

 

Un nouveau rapport de Page Experience dans la Search Console

 

Pour vous fournir des informations plus exploitables, Google annonce le déploiement d’un rapport Page Experience.

Ce rapport combine le rapport Core Web Vitals existant avec d’autres composants des signaux d’expérience de page, tels que la sécurité , l’absence d’interstitiels intrusifs, l’état de navigation sécurisé et le mobile-friendly.

Le rapport Page Experience offre des mesures précieuses, telles que le pourcentage d’URL avec une bonne expérience de page et des impressions de recherche au fil du temps, vous permettant d’évaluer rapidement les performances.

Vous pouvez également creuser dans les composants du signal de Page Experience pour obtenir des informations supplémentaires sur les possibilités d’amélioration.

Vous pouvez également creuser dans les composants du signal de Page Experience pour obtenir des informations supplémentaires sur les possibilités d’amélioration.

 

En plus de lancer le rapport “Expérience sur la page”, (Section “Expérience” dans la colonne de gauche) nous avons également mis à jour le rapport “Performances dans les résultats de recherche” pour vous permettre de filtrer les pages avec une bonne expérience de page, ce qui vous aide à garder une trace de la façon dont ces pages se comparent à d’autres pages sur le même site.

 

Prise en charge des échanges signés pour tous les contenus sur Google Search

 

Aujourd’hui, Google annonce également la disponibilité générale des échanges signés (SXG) sur Google Search pour toutes les pages Web.

Google Search n’a auparavant pris en charge que SXG construit avec le framework AMP.

SXG permet à Google Search de tirer parti de la technique de pré-verrouillage de la protection de la vie privée dans les navigateurs compatibles, ce qui peut conduire à une meilleure expérience de page.

Cette technique permet à Google Search de charger les ressources clés d’une page (HTML, JavaScript, CSS) avant la navigation, ce qui permet au navigateur d’afficher les pages plus rapidement.

Pour être clair, « l’utilisation de SXG n’est pas une exigence pour les avantages d’expérience de page, et vous pouvez considérer la technologie comme l’une des options pour améliorer votre Page Experience », a déclaré Google.

Au final, nous avons tous un peu plus de temps pour nous préparer à cette prochaine mise à jour de Page Experience.

Source : Searchengineland

L’algo Google Page Experience Update ne sera pas en temps réel !

La prochaine mise à jour de Google Page Experience qui est supposée être lancée le mois prochain ne va pas être en temps réel, comme certains des autres updates de l’algorithme de .

L’algo Google Page Experience Update ne sera pas en temps réel !

 

C’est un peu évident, puisque nous savons qu’il y a un délai de 28 jours dans la collecte des données de Core Web Vitals.

 

Question : Cet algorithme Page Experience qui arrive en Mai, je voulais juste savoir s’il s’agit d’un algorithme en temps réel ou quelque chose comme les Core Algorithm Updates où il sera mis à jour de temps en temps ?

 

Réponse de John Mueller : Je ne sais pas, je ne sais pas si c’est encore décidé complètement. Je veux dire qu’une partie de cela est aussi un délai général pour les données de toute façon. Nous devons donc attendre cette période jusqu’à ce que nous ayons recueilli suffisamment de données.

Donc, je soupçonne que ce n’est pas quelque chose qui sera optimisée pour la vitesse de chargement, les Speed Updates, mais plus une sorte d’avoir une compréhension claire de l’image globale. Donc, je suppose que ce sera plus une chose plutôt lente que d’un changement de temps réel.

Quand Google mettra-il à jour les données de Chrome User Experience (CrUX) dans le cycle de 28 jours ? Eh bien, il n’y a pas de date précise, ce n’est pas seulement le 1er du mois.

scores CWV ?

Il faut 28 jours pour mettre à jour les données de CrUX (GSC montre juste cela), qui est la base de ce que nous utilisons. Gardez également à l’esprit qu’ils n’ont pas tous * besoin * d’être « bons », nous utilisons beaucoup de facteurs pour le classement, et se rapprocher de Core Web Vitals est également utile.

Mais pour obtenir le meilleur avantage lors des mises à jour de l’algo, est-il préférable de les obtenir aussi près que possible que 28 jours avant le déploiement ? Ou peut-on continuer à travailler jusqu’au 1er Mai ?

Je ne pense pas qu’il y ait encore de date exacte choisie, donc il y a ça. Toutefois, cela signifie plus tôt que vous pouvez toujours itérer si les données sur le terrain ne sont pas comme prévues.

En outre, ce n’est pas une mesure qui est conservée pour toujours, vous pouvez continuer à travailler sur elle après le mois de Mai aussi.

Source : Seroundtable

Google met à jour les FAQs sur Core Web Vitals et Page Experience

a publié une page de questions fréquemment posées (FAQ) pour Core Web Vitals et Page Experience.

Google met à jour les FAQs sur Core Web Vitals et Page Experience

 

Google vient de mettre à jour ces FAQs pour ajouter beaucoup plus de détails.

Comme le souligne Seroundtable, la chose la plus importante, ce sont ces lignes :

Nos systèmes continueront à hiérarchiser les pages avec les meilleures informations dans l’ensemble, même si certains aspects de Page Experience sont en deçà.

Une bonne expérience de page ne l’emporte pas sur le fait d’avoir un contenu pertinent et de grande qualité.

En outre, Google a dit que vous n’avez pas besoin d’effacer tous les éléments Core Web Vitals pour être admissible dans le carrousel des Top Stories.

Google a donc écrit :

Avec le changement à venir dans le carrousel “A la une” des Stories, toutes les pages Web, indépendamment de leur statut d’expérience de page ou de leur score Core Web Vitals, sont éligibles pour le carrousel Top Stories.

Lorsque les modifications seront mises en ligne, la conformité aux politiques de contenu de sera la seule exigence, et nous utiliserons l’expérience de la page comme signal de classement sur toutes les pages.

Rappelons que l’Update Google Page Experience sera lancée en Mai 2021. Il ne faut pas pour autant s’attendre à voir les classements sur Google changer radicalement.

Dans ces nouvelles FAQ, Google dit avoir organisé les questions dans ce post en 3 sections : Mesures et Outils, Page Experience et Search, et .

 

Mesures et Outils

 

Q: D’où viennent les données de Core Web Vitals que Search considère ?

R : Les données proviennent du Rapport d’expérience utilisateur Chrome, qui est basé sur les visites réelles des utilisateurs et les interactions avec les pages Web (également connues sous le nom de données sur le terrain). Pour être clair, les données ne sont pas calculées sur la base de simulations de laboratoire de pages de chargement ou basées sur les visites d’un visiteur non humain comme Googlebot.

Q: Comment les scores pour les URL individuelles sont-ils calculés ? En d’autres termes, comment détermine-t-on si une page passe ou échoue à l’évaluation des éléments vitaux web ?

R : Les mesures sont calculées au 75e percentile sur une fenêtre de 28 jours. En utilisant le 75e percentile, nous savons que la plupart des visites sur le site (3 sur 4) ont connu le niveau cible de performance ou mieux. Si une page atteint les cibles recommandées pour les trois mesures, elle passe l’évaluation des éléments vitaux web.

Q: Comment un score est-il calculé pour une URL qui a été récemment publiée, et qui n’a pas encore généré 28 jours de données ?

R : Comme pour la façon dont Search Console rapporte les données d’expérience de page, Google peut utiliser des techniques telles que le regroupement de pages similaires et calculer des scores basés sur 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 sur le terrain n’ont pas besoin d’être inquiets.

Q : Pourquoi vois-je différentes valeurs métriques dans différents outils tels que Lighthouse et le Rapport d’expérience utilisateur Chrome ?

R : Les Core Web Vitals sont basés sur les visites réelles des utilisateurs, qui seront influencées par les conditions environnementales des utilisateurs et leurs interactions.

Des outils comme Lighthouse sont des simulations de laboratoire. Bien que Lighthouse puisse fournir une image point dans le temps de ce que les mesures peuvent être pour certains utilisateurs et quelles sont les possibilités d’amélioration, il peut différer des données recueillies en fonction des visites réelles des utilisateurs.

Q: Je ne vois pas la page que je recherche dans le rapport Core Web Vitals sur la Search Console.

R : Pour chaque type de problème, la Search Console répertorie un sous-ensemble d’URL. Ces URL sont représentatives de différents types de pages que votre site peut avoir.

Le but de ce rapport est d’aider les utilisateurs à découvrir les types de pages problématiques de sorte qu’ils peuvent être débogués dans des outils comme Page Speed Insights ou Lighthouse.

Google dit espérer qu’en réparant les schémas des problèmes exposés par l’examen des URL individuelles, le type de page entier serait amélioré.

Q: Les pages et pages noindex sont-elles « bloquées par des robots.txt » incluses dans l’ensemble de données CrUX (Chrome User Experience) ?

R : Vous pouvez accéder aux données CrUX de 2 façons : niveau page via Page Speed Insights (PSI) et l’API CrUX ou niveau Origine via Public Big Query Dataset.

La première ne fait la surface que des informations pour les pages indexables publiquement qui répondent également à un seuil de trafic, tandis que la seconde peut inclure des données agrégées de toutes les pages publiques et privées.

Q: Un service tiers que j’utilise (tels que les tests A/B côté client, l’intégration sociale, les moteurs de personnalisation, les systèmes de commentaires, etc.) ralentit mon site.

R : Les sites peuvent choisir d’utiliser une variété de code et de services tiers. Les mesures Core Web Vitals ne font pas de distinction dans ces choix, mais ne regardent que l’expérience totale observée de la page telle qu’elle est vue par l’utilisateur final.

Comme toutes les autres fonctionnalités d’une page, il peut être utile d’évaluer régulièrement l’impact des composants tiers de l’expérience sur les signaux web essentiels. Il peut y avoir une meilleure forme d’intégration ou de configuration qui améliore l’expérience utilisateur et sera reflétée avec des mesures Core Web Vitals améliorées.

Q: Pourquoi les conseils de Google utilisent-ils les mêmes seuils pour Core Web Vitals pour tous les types de pages ? Par exemple, une page d’accueil pour un journal n’est pas la même qu’un article et non la même chose qu’une page de commentaires.

R : Les Core Web Vitals sont censés être des mesures fondamentales qui s’appliquent à tous les types de pages.

Pour déterminer les plages de seuils, nous avons analysé une grande variété de pages et nous nous sommes inspirés de recherches axées sur les exigences fondamentales en matière d’expérience utilisateur agnostiques du type de page.

 

Page Experience et Search

 

Q: Quelle est la mise à jour de Page Experience et quelle est son importance par rapport aux autres signaux de classement ?

Nos systèmes continueront de hiérarchiser les pages avec les meilleures informations dans l’ensemble, même si certains aspects de l’expérience de page sont “critiques”. Une bonne expérience de page ne l’emporte pas sur le fait d’avoir un contenu pertinent et de grande qualité.

Ceci est similaire aux changements que nous avons eus dans le passé, tels que notre update du mobile-friendly ou notre Speed Update.

Comme avec ces signaux, l’expérience de page sera plus importante dans les types de situations de « tie-breaker ». S’il existe plusieurs pages de qualité et de contenu similaires, celles qui ont une meilleure expérience de page peuvent être plus performantes que celles qui n’en ont pas.

Mais les éditeurs devraient se concentrer sur l’amélioration d’une priorité relative au fil du temps. C’est parce que comme de plus en plus de sites continuent d’améliorer leur expérience de page, ce sera la norme que les éditeurs voudront égaler.

Q: Core Web Vitals est-il un facteur de classement lors de l’utilisation de sur les navigateurs non Chrome ?

R: Oui. Les signaux de classement de Page Experience, basés sur Core Web Vitals, sont appliqués globalement sur tous les navigateurs sur les appareils mobiles.

Q: Comment fonctionne le classement de Page Experience en ce qui concerne les conseils publiés sur les valeurs pour Core Web Vitals qui sont considérées dans le « bon » seuil ?

R : Les lignes directrices pour LCP, FID et CLS (les principaux signaux Web essentiels) décrivent chacune une valeur spécifique qui constitue un « bon » score. Parce que plus proche de zéro est mieux pour toutes ces mesures particulières, nous pouvons parler en termes de n’importe quel score entre zéro et la valeur documentée (inclusivement) comme étant la “bonne plage”.

Le classement de Page Experience de Google évalue chacun des Core Web Vitals individuellement comme signal de classement. L’impact du classement de Page Experience sera le même pour toutes les pages qui sont dans la bonne fourchette pour tous les Core Web Vitals, indépendamment de leurs scores Core Web Vitals individuels.

Par exemple, une page avec un LCP de 1750 ms (mieux que les « bonnes » orientations LCP) et une autre avec 2 500 ms (aux « bonnes » orientations) ne seraient pas distinguées sur la base du signal LCP. Toutefois, des centaines d’autres signaux, y compris les autres signaux web essentiels, pourraient entraîner un classement différent pour les deux pages en question.

En dehors de la bonne plage, des valeurs différentes d’une mesure Core Web Vital sur deux pages peuvent entraîner des classements d’expérience de page différents.

Q: Quelle version d’une page Web, si je publie des versions AMP et non AMP, sera liée par Google ?

R: La version AMP. Si les deux versions d’une page sont proposées, Google continuera à se lier à la version AMP de la page sur mobile, comme c’est le cas aujourd’hui.

Veuillez noter que pour le carrousel Top Stories, il y a une exigence supplémentaire de conformité aux politiques de contenu de Google Actualités.

Q: Comment un éditeur sait-il si ses pages bénéficient de Core Web Vitals dans le classement ?

R : Le classement de l’expérience de page concerne l’évaluation des pages en fonction de l’expérience utilisateur mesurée par Core Web Vitals, ainsi que d’autres critères.

Nous reconnaissons que les sites peuvent équilibrer les objectifs d’expérience utilisateur avec d’autres objectifs d’affaires. Les pages qui reçoivent un score de « bon » sur Core Web Vitals atteignent un niveau ambitieux d’expérience utilisateur, et pourraient obtenir un coup de pouce dans la composante d’expérience de page du classement, à condition que d’autres composants du signal Page Expérience (, mobile-friendly, etc) sont considérés comme OK.

Si vous avez des pages qui ne mesurent pas « bon » sur au moins une des mesures Core Web Vitals ou ne passent pas les critères d’expérience de l’autre page, nous vous recommandons de vous concentrer sur l’amélioration de ces dimensions au fil du temps.

Bien que tous les éléments de Page Expérience soient importants, nous prioriserons les pages avec les meilleures informations dans l’ensemble, même si certains aspects de l’expérience de page sont “subpar”. Une bonne expérience de page ne l’emporte pas sur le fait d’avoir un contenu pertinent et de grande qualité.

Toutefois, dans les cas où il existe plusieurs pages qui ont un contenu similaire, l’expérience de la page devient beaucoup plus importante pour la visibilité dans Search.

 

AMP et Top Stories

 

Q: Suis-je éligible pour le carrousel “Top Stories” si ma page Web n’est pas claire avec Core Web Vitals ?

R: Oui. Avec le passage prochain au carrousel Top Stories, toutes les pages Web indépendamment de leur statut Page Experience ou de leur score Core Web Vitals sont éligibles pour le carrousel Top Stories.

Lorsque les modifications seront mises en ligne, la conformité aux politiques de contenu de Google Actualités sera la seule exigence, et nous utiliserons Page Experience comme signal de classement sur toutes les pages.

Q: Cela signifie-t-il que l’AMP deviendra effectivement un signal de classement ?

R : L’AMP n’a jamais été un signal de classement et n’en devient pas un. Il s’agit d’un framework que les propriétaires de sites web peuvent utiliser pour créer des pages Web belles et performantes, et peuvent profiter de nombreuses fonctionnalités intégrées qui aident à améliorer l’expérience de la page.

Q: Mes pages AMP auront-elles toujours une bonne expérience de page ? Dois-je faire quelque chose si je suis déjà en AMP ?

R : Les contributeurs du projet AMP dans le monde entier se sont engagés à faire en sorte que les propriétaires de sites commencent bien vers une expérience performante lors de la création de pages AMP. Toutefois, comme beaucoup d’autres frameworks, AMP ne peut pas implémenter toutes les meilleures pratiques de développement web.

Q: Si les sites ne veulent plus utiliser AMP, y a-t-il des options ?

R : Oui, il y a beaucoup de chemins autres que l’AMP pour réaliser une grande expérience de page. Les propriétaires de sites peuvent utiliser une variété d’outils/frameworks de leur choix, et nous les encourageons à visiter la Search Console pour en savoir plus sur la façon dont leur site mesure sur les critères d’expérience de page comme Core Web Vitals.

Q: Comment puis-je savoir si mes pages AMP ont une bonne expérience de page ?

R : Le projet AMP a publié un outil, le Guide Page Experience de l’AMP, pour aider les sites à comprendre comment leur contenu AMP mesure selon les Core Web Vitals. Il fournit également des informations mesurables sur la façon d’améliorer les pages AMP.

Si une page AMP ne passe pas les Core Web Vitals et qu’il n’y a pas de rétroaction actionnable disponible, les développeurs sont encouragés à signaler ces problèmes à l’équipe AMP en utilisant les canaux de l’outil.

Q : Les signaux de classement de Page Experience ne regardent-ils que le contenu AMP chargé à partir d’un cache ?

R : Les signaux Page Experience d’une page sont déterminés en observant l’expérience offerte compte tenu des pages de trafic réelles que reçoivent les pages de trafic. Dans le cas d’AMP, cela signifie que les pages peuvent être servies à partir de l’origine de l’éditeur ou via un cache AMP, selon la façon dont l’utilisateur rencontre le contenu.

C’est pourquoi nous encourageons les développeurs qui utilisent AMP à s’assurer que les pages desservies à partir de ces deux sources sont optimisées. Nous recommandons aux développeurs d’utiliser les AMP Optimizers pour apporter des optimisations du Cache AMP à leur propre site.

Q: Comment les données de Google AMP Viewer sont-elles attribuées ?

R : Les signaux de Page Experience sont conçus pour refléter la façon dont les utilisateurs vivent le Web. Par conséquent, nous incluons les visites attribuées à la visionneuse Google AMP dans les données d’une URL AMP. Dans le cas de l’AMP appariée, la page canonique non AMP est attribuée indépendamment.

Q: Google continue-t-il d’investir dans AMP ?

R : Google Search s’est concentré sur le fait de s’assurer que les utilisateurs ont une grande expérience de page lorsqu’ils s’engagent avec du contenu Web. L’expérience de page est un ensemble de signaux qui mesurent la façon dont les utilisateurs perçoivent l’expérience d’interagir avec une page Web au-delà de sa valeur d’information pure.

Le projet AMP continuera de se concentrer sur la création d’expériences utilisateur fortes, ce qui inclut l’ à l’état des signaux de Page Experience.

Google continue d’investir dans AMP, et croit fermement en l’objectif du projet AMP de fournir des pages Web qui fournissent une grande expérience utilisateur. Google Search continuera de diriger les utilisateurs vers les versions AMP des pages Web lorsqu’elles seront disponibles.

Cela permet aux utilisateurs de bénéficier des améliorations de vitesse qui proviennent de privacy-preserving prerendering et des caches AMP.

Q: Quelles sont les considérations pour les éditeurs qui envisagent de désactiver AMP afin d’avoir une bonne expérience de page ?

R : Les objectifs d’expérience utilisateur et d’expérience de page d’AMP sont étroitement alignés, et donc l’AMP est une solution simple et rentable pour les éditeurs qui cherchent à créer des pages Web avec une bonne expérience de page avec un minimum d’efforts continus.

Toutefois, l’AMP a certaines contraintes que les éditeurs peuvent rencontrer – par exemple, il peut être difficile de créer des expériences interactives complexes, et les services tiers que les éditeurs peuvent envisager d’utiliser ne sont pas toujours intégrés à l’AMP.

Sur la monétisation, AMP équilibre la priorité de l’expérience utilisateur avec la capacité d’un éditeur à gagner des revenus, et les éditeurs peuvent optimiser le potentiel de revenus de leurs pages AMP en suivant les lignes directrices ici.

Si les éditeurs envisagent de s’éloigner de l’AMP, il est probable qu’il y aura un certain investissement nécessaire pour avoir une bonne expérience de page. Les éditeurs qui maintiennent des pages non AMP n’auront aucune limite sur les types de technologies qu’ils utilisent pour créer une expérience de page, mais certains éléments peuvent avoir besoin d’être optimisés pour s’assurer qu’ils permettent une bonne expérience de page.

Les éditeurs qui cherchent à désactiver les pages AMP peuvent suivre les directives énoncées ici.

Q: Si les éditeurs décident de ne pas utiliser AMP, comment sauront-ils que leur contenu est éligible au carrousel Top Stories ?

R : Avec le passage prochain à Top Stories, le contenu de tout éditeur de news, que ce soit via AMP ou une autre technologie, est éligible à condition qu’il soit conforme aux politiques de contenu de Google Actualités.

La question de savoir si le contenu apparaît dans la pratique dépendra d’un certain nombre de facteurs pris en compte dans le classement, et les critères de Page Experience seront l’un d’entre eux. Pour être clair, tout contenu indépendamment de ses paramètres d’expérience de page est éligible pour la fonctionnalité Top Stories sur Google Search.

Q: Si mes pages AMP n’ont pas une bonne expérience de page, sont-elles toujours éligibles pour le Carrousel Top Stories ?

R : Oui, tout contenu qui répond aux politiques de contenu google actualités peut être affiché dans le carrousel Top Stories.

Page Experience se réfère à une collection de signaux qui sont tous importants pour fournir une bonne expérience de page, et les signaux deviennent un facteur dans le classement, y compris dans le carrousel Top Stories.

Cela signifie que les facteurs de Page Experience, en plus de nombreux autres facteurs, y compris le contenu lui-même et la correspondance à la requête, déterminera son placement dans le carrousel Top Stories. Les éditeurs devraient se concentrer sur l’amélioration de l’expérience de page une priorité relative au fil du temps que le classement de l’expérience de page devient la norme que les utilisateurs attendent et d’autres éditeurs voudraient correspondre.

Q: Si j’arrête de faire AMP et d’utiliser une approche différente pour publier du contenu, y compris l’optimisation de l’expérience de page sur mon propre site, puis-je m’attendre à ce que Google classe mon contenu de la même manière que lorsque je l’ai fait AMP ?

R: L’expérience de page est conçue comme un signal de classement agnostique de la technologie. Les développeurs peuvent travailler dans le cadre de leur choix. Le passage de l’AMP à l’utilisation d’une approche différente ne prendra pas en compte la façon dont les pages non AMP sont classées.

Q: Que dois-je considérer d’autre si je décide d’arrêter d’utiliser AMP ? Quel impact cela aura-t-il sur la façon dont mon contenu apparaît dans Google Discover ou Google Actualités ?

R : Bien que le flux Discover affiche beaucoup de contenu AMP, AMP n’est pas une exigence ni un facteur de classement pour servir dans cet espace. Les fiches d’article pour les pages AMP sont automatiquement éligibles pour utiliser une image miniature plus grande.

Ces images plus grandes ont un taux de clics plus élevé que les images miniatures plus petites.

Dans ce contexte, nous vous recommandons que si vous décidez d’aller en dehors d’AMP, vous rendez des images plus grandes à la disposition de Google pour votre contenu non AMP. Vous pouvez le faire en ajoutant le paramètre de balises meta robots “max-image-preview:[large]” sur chaque page.

Q: Pour les publications qui utilisent AMP, comment devraient-elles penser à la façon dont elles vont apparaître dans l’application Google Actualités ?

R : Aujourd’hui, l’application Google Actualités affiche le contenu AMP lorsqu’il est disponible, mais ne se limite pas au seul contenu AMP.

L’équipe de l’application Google Actualités travaille à élargir davantage le support des pages Web non AMP et à optimiser en fonction de Page Experience.

Nous soutiendront nos partenaires d’édition qui sont intéressés à passer de l’AMP à la non-AMP s’il s’agit d’un changement qu’ils explorent.

Source : Google

Le SEO est à la poursuite des Core Web Vitals de Google

Mai 2021 sera une date importante pour le monde de l’Internet et du référencement Web.

Le SEO est à la poursuite des Core Web Vitals de Google

 

C’est le mois où Google commence à introduire des signaux via l’Expérience de Page, comme un facteur de classement pour la page de résultats du moteur de recherche.

Google charge les utilisateurs de logiciels CMS comme WordPress et non les développeurs de CMS de les corriger ou de les réparer pour les Core Web Vitals. Est-ce juste ?

Vous n’êtes pas seul si vous avez du mal à améliorer les scores de Core Web Vitals et à venir à court. Des données anecdotiques suggèrent qu’il est difficile d’obtenir des performances Core Web Vitals élevées.

La raison en est que les éditeurs et les référenceurs SEO tentent de réparer quelque chose qui techniquement n’est pas cassé.

 

Changement de paradigme dans la façon dont les sites sont développés

 

Nous en sommes aux premières étapes d’un changement de paradigme majeur dans la façon dont les pages Web sont créées. Un hébergeur web plus rapide est utile, mais il ne répare pas les problèmes de Core Web Vitals.

Les Core Web Vitals sont calculés en aval de l’appareil mobile qui affiche vos pages Web sur un téléphone mobile à des vitesses 3G ou 4G.

C’est de là que proviennent les données des Core Web Vitals et qu’un serveur Web rapide est peu utilisé à ce moment-là si le téléchargement est étranglé par une mauvaise connexion Internet au téléphone.

L’amélioration des Core Web Vitals est moins sur l’hébergement web et plus sur la correction du code.

 

Réparer ce qui n’est pas cassé

 

WP Rocket a récemment refondé son site web en utilisant Gutenberg.

C’était une décision courageuse et presque téméraire étant donné que Gutenberg n’avait pas toutes les capacités d’édition du site à l’époque.

Ils ont dû personnaliser la façon dont WordPress gère le CSS et le JavaScript afin d’améliorer les scores de Page Experience de Google.

En d’autres termes, en refondant leur site Web pour être bien noté pour Core Web Vitals, WP Rocket a dû personnaliser WordPress lui-même, pour en faire quelque chose qu’il n’a pas été conçu pour être.

 

Core Web Vitals pas vraiment friendly

 

Les normes de Core Web Vitals ne sont pas quelque chose que les développeurs de WordPress ont à l’esprit lors de la création du site WordPress.

C’est pourquoi l’intégration de Tweets (et ça c’est vrai !) dans un post déclenchera le Cumulative Layout Shift.

WordPress et les thèmes ne codent pas pour Google. Ils codent pour les besoins des éditeurs.

Il n’y a pas que WordPress, non plus. La plupart des autres systèmes de gestion de contenu (CMS) ne sont pas intégrés aux meilleures pratiques des Signaux Web Essentiels (Core Web Vitals).

Cela ne signifie pas qu’il y a quelque chose de mal avec WordPress. Il n’y a rien de mal avec WordPress parce que Google dit qu’il y a quelque chose de mal.

 

Core Web Vitals n’est pas un problème WordPress

 

Core Web Vitals est un ensemble de mesures développées indépendamment par Google et poussées vers l’éditeur et la communauté SEO pour travailler avec.

WordPress n’a rien à voir avec ça.

Core Web Vitals est apparu en Mai 2020, apparemment sans aucune coordination ou consultation avec l’écosystème des développeurs.

Du côté de WordPress, le développement va de l’avant comme si Core Web Vitals n’existait pas. Alors que du côté de l’éditeur et du SEO, ce sont les utilisateurs de WordPress qui sont accablés par la tâche de « correction » de WordPress, Drupal, phpBB, de Google, etc.

Dans un monde parfait, le travail de création d’un système qui répond aux besoins des utilisateurs se trouve du côté des développeurs. Mais ça n’arrive pas. WordPress ne voit même pas Core Web Vitals comme un problème WordPress.

Quand quelqu’un a commencé un thread de support dans les forums WordPress à ce sujet, on lui dit de poser sa question dans le forum de support de Google.

Vous devriez le demander sur un forum Google, parce que WordPress n’a rien à voir avec cela.

 

L’éditeur et la communauté SEO accablés par la conformité

 

Les éditeurs de WordPress sont coincés à essayer de rendre les sites Web conformes à une norme pour laquelle ces sites Web n’ont jamais été conçus pour se conformer.

C’est la raison pour laquelle tant de gens sont aux prises avec les Core Web Vitals. Les éditeurs et les SEOs sont accablés d’essayer de réparer quelque chose qui, idéalement, devrait être corrigé au niveau du code.

Améliorer les scores Core Web Vitals peut sembler avoir envie d’essayer d’améliorer les performances d’une Honda Civic aux normes d’une Chevrolet Corvette.

Les développeurs n’ont pas construit de Corvette. Ils ont construit une Honda Civic.

Mais Google exige que les conducteurs (et non les fabricants) améliorent les performances à un niveau Corvette. Cela vous semble-t-il juste ?

Est-il raisonnable de demander aux utilisateurs d’un logiciel CMS de l’améliorer plutôt qu’aux développeurs du logiciel ?

Le problème de la conformité logicielle avec Core Web Vitals existe au niveau du code, pas au niveau de l’utilisateur-éditeur de contenu.

Alors, pourquoi les éditeurs et la communauté SEO sont-ils accablés de réparer quelque chose dont ils ne sont que des utilisateurs ?

 

Google est-il d’une aide quelconque ?

 

Google fournit beaucoup d’outils pour diagnostiquer les problèmes et offre des articles en profondeur expliquant comment résoudre ces problèmes de codage.

Mais ce sont des problèmes de codage du CMS et non des problèmes d’utilisateurs.

Un exemple de la déconnexion entre la communauté de développement et Google est le problème de Cumulative Layout Shift, où la page Web se déplace et se réorganise au fur et à mesure que les éléments de la page sont téléchargés.

Une raison commune pour le Cumulative Layout Shift est que les images n’ont pas une hauteur et une largeur déclarées. Google recommande des solutions de contournement exotiques comme l’utilisation de CSS pour coiffer les images à l’aide de box de ratio d’aspect.

L’éditeur et le SEO moyen ne vont probablement pas comprendre ce que les boîtes de ratio d’aspect sont et comment calculer les ratios à l’échelle du site d’une manière qui ne casse pas le site.

Jetez un oeil à cela et à la description des boîtes de ratio d’aspect que Google lie, pour voir si cela a du sens pour vous :

Les carrés parfaits et des choses en 16:9 sont grands, mais les valeurs utilisées pour ceux-ci ne sont que des mathématiques simples. Un rapport d’aspect peut être n’importe quoi, et ils sont généralement complètement arbitraires. Une vidéo ou une image peut être recadrée à n’importe quelle taille.

Alors, comment pouvons-nous comprendre le padding-top pour notre 1127.34 × 591.44 SVG ci-dessus ?

Une façon est d’utiliser calc (), comme ceci :

padding-top: calc(591.44 / 1127.34 * 100%);

Voici un autre exemple.

De nombreux modèles Web règlent régulièrement les largeurs d’image via CSS pour qu’elles soient automatiques (width : auto;) sans définir la hauteur et la largeur des images

Il s’agit d’une pratique de codage courante qui provoque le Cumulative Layout Shift (CLS).

Ce sont les raisons pour lesquelles WP Rocket a dû creuser et apporter des modifications au CSS et JavaScript du site à l’échelle du site.

Par exemple, WordPress Gutenberg charge tout le CSS qui existe, qu’il soit nécessaire ou non. Le développeur de WP Rocket a donc dû remettre du code pour cela.

C’est ainsi que WP Rocket a expliqué ce qu’ils ont fait dans le cadre de leur refonte :

Nous avons également décidé de ne pas utiliser le fichier Gutenberg CSS. Au lieu de cela, nous avons « migré » le CSS dont nous avions réellement besoin dans notre propre feuille de style, dans un fichier CSS dédié. Cela a fait l’affaire.

 

Repenser la façon dont les sites sont créés

 

Il est important de comprendre le problème des Core Web Vitals. Google exige que les éditeurs et les SEOs créent des solutions pour lesquelles la communauté de développement CMS ne montre aucun intérêt pour les traiter.

Voici un exemple des types de compromis auxquels nous sommes confrontés et comment Google change la façon dont nous développons des sites Web.

Parlons des polices.

Rendre le blocage des ressources tierces peut avoir un impact négatif sur “Largest Contentful Paint”. Un goulot d’étranglement commun est le téléchargement des polices à partir d’un site tiers comme Google Fonts.

Il y a un certain nombre de trucs à appliquer qui sont la combinaison de l’utilisation de l’attribut de lien de préchargement et peut-être certains JavaScript, etc, qui rendent le processus de téléchargement de polices tierces compatibles avec Core Web Vitals.

Mais cela tuerait-il votre site que de laisser cette police fantaisiste derrière ?

Une solution simple qui aidera à avoir un meilleurs score est de passer de la police du site Web à une police sans serif que les appareils , et ont déjà chargé dans leur système.

Passer à une police attrayante qui est intégrée dans l’appareil signifie que le site n’a plus à attendre pour télécharger une police fantaisiste.

Une approche peut être quelque chose comme ceci :

police-family: Helvetica, Tahoma, sans-serif;

Si Android n’a pas Helvetica ou Tahoma déjà chargé dans le navigateur, alors l’appareil affichera le site en utilisant la police Roboto.

Pour les personnes habituées à utiliser des polices de fantaisie, l’utilisation de polices système peut sembler extrême. Mais c’est un exemple des types de compromis qu’un éditeur web peut avoir besoin de faire, en particulier les éditeurs qui sont dans des créneaux hautement concurrentiels.

Ce genre de décision est une évidence pour un site affilié axé sur la vitesse de chargement de la page et les conversions.

 

Un moment de transition

 

Ce qui se passe aujourd’hui, c’est que nous vivons un moment de transition. Les choses changent, de la façon dont nous avons fait les choses dans le passé à la façon dont les développeurs vont faire les choses (hors de la box) à l’avenir.

Les développeurs ont répondu à la demande de sites mobile-friendly. Avec le temps, ils peuvent commencer à répondre à la demande de sites qui obtiennent de bons scores pour Core Web Vitals.

La façon dont les systèmes CMS, les templates et les plugins sont conçus n’a pas été à la hauteur des besoins des éditeurs qui ont besoin de tenir compte des Core Web Vitals.

Pour l’instant, les SEOs techniques et la communauté des développeurs sont coincés à l’idée d’avoir à « corriger » ce qui n’est pas cassé dans le site afin de le faire respecter l’idée de Google de ce à quoi le web devrait ressembler.

Bien sûr, une page qui se charge rapidement et ne se déplace pas autour est une bonne chose. Mais exiger des utilisateurs d’un logiciel CMS d’améliorer le logiciel lui-même est un vrai fardeau.

À ce stade, le fardeau de la fixation du code incombe aux utilisateurs du logiciel de publication et non aux développeurs de ce logiciel. Vous trouvez ça normal, vous ?

Ce qui pourrait arriver, c’est que certains peuvent trouver utile de corriger autant qu’ils le peuvent et laisser le reste pour quand WordPress et d’autres logiciels CMS rattraperont le coup.

 

5 solutions pour améliorer les Core Web Vitals rapidement

 

Déjà, on a beaucoup parlé des principaux éléments des Signaux Web Essentiels. Plus particulièrement, comment accélérer un site Web.

C’est principalement parce que, des principaux éléments des Core Web Vitals, ce sont ceux qui sont liés à la vitesse de chargement du site web qui ont la pondération la plus élevée.

Bien sûr, beaucoup d’attention devrait être portée à l’amélioration de la vitesse du site. Toutefois, si vous voulez que tous les 3 éléments des Core Web Vitals passent au vert, vous allez devoir faire un peu plus que cela.

Avec cela, voici 5 façons faciles qui devraient aider à améliorer vos principaux Core Web Vitals.

  • Mettre en œuvre un CDN : Un CDN (Content Delivery Network) est un excellent moyen de s’assurer que votre site web est rapide pour tous les utilisateurs web à travers le monde. Il permet de réduire la distance entre l’utilisateur web et sa demande et l’emplacement du serveur pour obtenir les informations (où un CDN utilise plusieurs serveurs pour fournir des ressources).
  • Utilisez un cache : Que donne 1593 x 4529 ? La réponse est 7 214 697, si vous avez passé le temps pour calculer cela.

    Maintenant, si je vous demande ce qu’est encore 1593 × 4529, sachez qu’il est de 7 214 697, comme nous venons de le calculer, et de faire un dossier.

    C’est exactement ce qu’un cache fait. Il peut améliorer radicalement la vitesse d’une page Web en pré-calculant la page avant que l’internaute n’y arrive.

  • Reporter de tout JavaScript, y compris les annonces : Vous voudrez supprimer ou reporter tous les scripts de blocage de rendu qui pourraient influencer la vitesse de chargement de votre site Web.

    Javascript empêche la page réelle d’être chargée dès le début. Ainsi, une meilleure façon d’améliorer le temps de chargement perçu est de « reporter » (repousser) les scripts, de sorte que la page se charge, puis les scripts.

  • Assurez-vous que votre police d’arrière-plan est un match similaire : La plupart des sites Web utiliseront une police Google (Google Fonts). Le problème avec cela, comme nous l’avons vu plus haut dans cet article, est que, au moment du chargement, le texte se chargera sur la page, en utilisant une police de sauvegarde, puis chargera la police Google une fois que la demande de police a été chargée.

    Cela peut causer du Cumulative Layout Shift (CLS) en raison d’une grande différence entre la police de sauvegarde et la police Google.

    Ce que vous pouvez faire est d’utiliser cet outil Font Police Matcher pour choisir une police de sauvegarde aussi proche de la police Google que vous utilisez.

  • Purgez vos plugins inutiles : Soyons honnêtes. Avez-vous besoin de chaque plugin unique sur votre site ? Vous trouverez probablement un ou deux plugins qui sont futiles ou peuvent être remplacés par quelque chose de beaucoup plus simple.

    Si vous pouvez trouver des exemples pour cela sur votre site Web, faites exactement cela. Moins il y aura de code à charger sur un site Web, plus celui-ci sera rapide.

Bref, Google devrait cependant admettre que tout changement à réaliser pour rendre un site plus performant pour les Core Web Vitals devrait idéalement revenir aux développeurs d’outils de création de site CMS (sur lesquels il devrait exercer une pression forte) et non aux simples utilisateurs de CMS (WordPress, Blogger, Wix, Drupal, etc) que nous sommes.

Source : Searchenginejournal