La mise à jour de CLS dans Core Web Vitals est effective

En avril, Google a mis à jour la façon dont la métrique CLS (Cumulative Layout Shift) dans les Core Web Vitals était calculée.

La mise à jour de CLS dans Core Web Vitals est effective dans la Search Console

 

En bref, a rendu la métrique CLS plus bénéfique pour la plupart des sites, de sorte que vos scores CLS peuvent augmenter d’eux-mêmes depuis le 1er juin dans les rapports de la .

Le 1er Juin 2021, Google a publié ce qui suit sur sa page “Data anomalies in Search Console” :

Les mesures CLS ont été mises à jour pour refléter une représentation plus précise des changements de mise en page (layout shifts) sur la page.

Vous pouvez voir des changements dans les statuts CLS de votre page (pour la plupart positifs) reflétant ce changement.

C’est après que Google a publié le 13 avril le même message exact.

Mais Seroundtable dit avoir confirmé avec Google que cela signifie que Google a noté le changement qui se produisait en Avril, mais les scores CWV eux-mêmes n’ont pas été reflétés dans la Search Console avant le 1er Juin.

Jeffery Jose de chez Google a déclaré sur :

Les changements du 1er Juin reflètent la définition mise à jour de CLS telle que décrite dans le post https://web.dev/evolving-cls/.

Il a fallu quelques semaines de travail pour faire passer la mise à jour de CrUX (Chrome User Experience) à la Search Console.

Par conséquent, vous devriez voir des améliorations dans vos scores CLS sans rien faire.

Consultez donc votre rapport “Signaux web essentiels” dans Console et attendez-vous à plus de barres vertes de la métrique CLS.

Google a modifié la mesure Cumulative Layout Shift de Core Web Vitals

a apporté des modifications à la façon dont il calcule le CLS, Cumulative Layout Shift, qui est une mesure des Core Web Vitals. Fenêtre de session spécifiquement maximale avec 1 seconde d’écart, plafonnée à 5 secondes.

a modifié la mesure Cumulative Layout Shift de Core Web Vitals

 

Avez-vous déjà visité un site Web et étiez sur le point de cliquer sur un lien vers un article, puis … la mise en page se déplace soudainement, une publicité apparaît, et en quelque sorte au lieu de cliquer sur l’article que vous vouliez lire, vous cliquez sur l’annonce inutile ?

Ce mouvement soudain sur la page est appelé “Layout Shift” ou changement de mise en page.

Cumulative Layout Shift (CLS) est donc une mesure calculée en résumant tous les changements de mise en page qui ne sont pas causés par l’interaction utilisateur. CLS examine la proportion du viewport qui a été touchée par les changements de disposition et la distance de déplacement des éléments qui ont été déplacés.

 

Qu’est-ce qu’un bon score CLS ?

 

Un score CLS peut être aussi bas que 0 pour les pages entièrement statiques et augmente plus les changements de layout se produisent sur la page.

Plus votre score est bas, plus votre layout est stable. Les scores CLS officiels utilisés par les outils de performance de Google sont les suivants :

  • Bon – CLS en dessous de 0,1
  • Besoin d\’amélioration – CLS entre 0,1 et 0,25
  • Pauvre – CLS au-dessus de 0,25

Google vous recommandait de garder votre score CLS en dessous de 0,1.

Nous avons reçu beaucoup de commentaires très utiles et après avoir terminé l’analyse à grande échelle, nous avons finalisé le changement que nous prévoyons d’apporter à la mesure: fenêtre de session maximale avec 1 seconde d’écart, plafonné à 5 secondes.

Google a déclaré qu’il a décidé d’aller de l’avant avec les fenêtres plus petites, plafonnées, maximum.

Cela peut avoir un impact sur vos scores CLS dans les Core Web Vitals. Voici un peu à quoi cela ressemble :

Cela peut avoir un impact sur vos scores CLS dans les principaux Core Web Vitals

 

Pourquoi 5 secondes ?

 

Google dit avoir évalué plusieurs tailles de fenêtres et trouvé deux choses :

  • Pour les fenêtres réduites, des chargements de page plus lents et des réponses plus lentes aux interactions utilisateur pourraient briser les changements de Layouts Shift en plusieurs fenêtres et améliorer le score.Nous voulions garder la fenêtre assez grande pour qu’elle ne récompense pas les ralentissements !
  • Il y a quelques pages avec un flux continu de petits changements de layouts shift. Par exemple, une page de score sportif qui se déplace un peu à chaque mise à jour de score.Ces changements sont ennuyeux, mais ils ne deviennent pas plus ennuyeux au fur et à mesure que le temps passe. Nous voulions donc nous assurer que la fenêtre était plafonnée pour ce type de changements de layout.

Avec ces deux choses à l’esprit, en comparant une variété de tailles de fenêtres sur de nombreuses pages Web du monde réel, Google dit avoir conclu que 5 secondes serait une bonne limite à la taille de la fenêtre.

 

Comment cela affecte-t-il le score CLS de ma page ?

 

Google déclare dans son post :

Étant donné que cette mise à jour plafonne le CLS d’une page, aucune page n’aura un score pire à la suite de ce changement. Et d’après notre analyse, 55% des origines ne verront pas du tout de changement dans le CLS au 75e percentile.

C’est parce que leurs pages n’ont actuellement pas de layout shifts ou décalages de mise en page ou les layouts qu’ils ont sont déjà confinés à une seule fenêtre de session.

Le reste des origines verra des scores améliorés au 75e percentile avec ce changement. La plupart ne verra qu’une légère amélioration, mais environ 3% verront leurs scores s’améliorer, qu’il s\’agisse de « besoins d’amélioration » ou d’un score « médiocre » ou d’un score « bon ».

Ces pages ont tendance à utiliser des défileurs infinis ou ont de nombreux layouts lents de l’interface utilisateur, comme décrit dans notre post précédent.

Google dit qu’il mettra bientôt à jour ses outils pour utiliser la nouvelle définition métrique !

D’ici là, vous pouvez essayer la version mise à jour de CLS sur n’importe quel site en utilisant l’exemple JavaScript des implémentations ou la fourche de l’extension Web Vitals.

Core Web Vitals : Comment améliorer LCP, FID et CLS ?

Il s’agit d’une mise à jour majeure de l’algorithme qui rassemblera une grande variété de mesures connues sous le nom de Core Web Vitals pour former un facteur de classement de l’expérience de page

Core Web Vitals : Comment améliorer LCP, FID et CLS ?

 

Il est prévu de se produire en Mai 2021, de sorte que vous avez un certain temps pour répondre à tous les changements qui doivent être apportés à votre site Web.

En quoi est-ce différent ?

Google annonce rarement des mises à jour d’algorithmes avant leur sortie, sauf les plus importantes (les updates), ce qui aura un impact significatif sur la façon dont Google classe les sites Web.

L’impact sur les sites Web individuels peut être minime, en particulier pour les industries qui ont déjà priorisé les temps de chargement des pages et la qualité de l’UX, mais peut être important pour nicher les sites de commerce électronique, blogs d’actualités et plus encore avec des expériences utilisateur obsolètes.

Google poursuit sa charge d’améliorer les performances du Web mobile ici. En commençant par le passage à (aidant à éliminer la stigmatisation entourant l’achat sur les réseaux non sécurisés), puis le passage à l’index mobile-first, Google a clairement indiqué que la recherche mobile est l’avenir.

Maintenant, en récompensant les sites au chargement rapide, Google établit la feuille de route pour le succès des entreprises en ligne et des sites Web.

 

C’est quoi les Core Web Vitals ?

 

Les , ce sont 3 mesures qui marquent l’expérience d’un utilisateur lors du chargement d’une page Web.

Ces mesures marquent la vitesse à laquelle le contenu de la page se charge.

La rapidité avec laquelle un navigateur charge une page Web peut répondre à l’entrée d’un utilisateur et l’instabilité du contenu telles qu’elle se charge dans le navigateur.

Ces trois mesures vont être regroupées aux côtés de la compatibilité mobile, de la navigation sécurisée, de https et des interstitiels intrusifs dans un signal que Google appelle le « signal Experience Page ».

  1. LCP – Largest Contentful Paint :C’est simplement le point dans lequel le contenu principal d’une page est chargé. Vous avez peut-être entendu votre équipe de développement ou un référenceur mentionner des choses comme le DOM ou DOMContentLoad dans le passé.C’est similaire, mais Google prétend qu’il s’agit d’une mesure plus simple qui regarde le temps de rendu de la plus grande image visible ou bloc de texte.Donc, en d’autres termes, si vous avez une grande image sur votre site, ou un arrière-plan vidéo qui prend beaucoup de temps à se charger, vous êtes en difficulté.

    De même, si vous avez une grande quantité de rendu bloquant JS ou CSS (un autre sujet préféré des ), ou votre site est configuré avec le rendu côté client, vous aurez probablement à passer un certain temps dans les prochains mois à améliorer votre LCP pour mieux répondre aux nouvelles lignes directrices de Google.

  2. CLS – Cumulative Layout Shift :

    Avez-vous déjà été sur un site Web lorsque l’ensemble du contenu a changé vers le haut ou vers le bas ? Parfois, plus d’un élément est déplacé ou déplacé plusieurs fois.Presque comme si la mise en page se déplaçait à chaque fois que quelque chose se chargeait sur la page et tout cela s\’ajoutant à un tas de déplacements d’une manière, plus ou moins, cumulative …Oui, vous l’avez deviné, c’est finalement marqué comme une expérience utilisateur terrible, très décevante…

    Le groupe Google web.dev a partagé cette vidéo fantastique qui met en lumière cette expérience :

    Alors, comment comprenons-nous et abordons-nous cette question ?

    Fondamentalement, les ressources et le contenu sont chargés sur la page après et au-dessus du contenu existant.

    Peut-être que vous avez une image qui est trop grande et vous avez choisi de la reporter une fois que le contenu critique est chargé. Peut-être qu’il y a une publicité qui pousse vers le bas le contenu après avoir chargé tout le reste sur votre page. Peut-être qu’il y a un widget dans la barre latérale qui pousse l’article principal vers la droite.

    Tous ces exemples sont des exemples d’instabilité de la mise en page qui comptent pour un Cumulative Layout Shift (décalage de mise en page cumulative, en français littéral), qui est une mesure par un score basé sur la somme de tous les changements de mise en page inattendus

  3. FID – First Input Delay :

    Lorsque nous chargeons des pages Web dans un navigateur, en tant qu’utilisateurs, nous nous attendons généralement à ce que la seconde où nous voyons un élément visuel, tel qu\’un bouton, une image ou une barre de défilement, se charger sur l’écran que la page est immédiatement prête à recevoir mon entrée.Cette attente est que nous pouvons cliquer sur le bouton ou faire défiler la page, même si la page semble toujours être en train de charger.Nous trouvons cela frustrant lorsque notre expérience ne répond pas à cette attente et qu’une page ne commence pas à répondre à nos actions.

    La réalité est que souvent, le navigateur ne peut pas répondre parce qu’il est occupé à analyser un grand JavaScript qui contrôle une fonction sur la page. Pendant que le navigateur charge ce fichier, il n’a pas les ressources nécessaires pour exécuter les auditeurs d’événements qui répondraient à l’entrée de l’utilisateur.

    Le premier délai d’entrée ou First input delay (FID) permet de quantifier cette frustration de l’utilisateur en une mesure centrée sur l’utilisateur. Il est important de noter que FID ne mesure pas le temps de traitement des événements ou le temps qu’il faut pour apporter des modifications à la mise en page ou au contenu, mais seulement le retard dans le traitement de l’événement initié par l’utilisateur.

    Dans l’exemple ci-dessus, que l’on peut trouver sur https://web.dev/fid/, nous pouvons voir un solide exemple de mesure FID. Dans ce scénario, un utilisateur a commencé à charger la page.

    Comme le contenu de la page se charge et commence à rendre, le thread principal du navigateur est occupé à exécuter des tâches comme le chargement d’un fichier JavaScript.

    La page a déjà commencé à charger des éléments visuels, et l’utilisateur voit quelque chose d’intéressant et tente d’interagir avec la page.

    Étant donné que le thread principal est déjà activement engagé dans d’autres tâches, il doit retarder l’action sur l’entrée de l’utilisateur jusqu’à ce que la tâche actuelle soit terminée. Le temps entre le moment où l’utilisateur a essayé d’engager avec la page et le moment où le navigateur peut réellement répondre à l’entrée de cet utilisateur est ce qu’on appelle FID.

 

Évaluer vos Core Web Vitals

 

Maintenant que nous savons tout sur les Core Web Vitals, comment pouvons-nous savoir où en sont nos pages ? Heureusement, il existe quelques façons d’analyser votre site.

L’utilisation de Console est le moyen le plus simple pour corriger plusieurs pages sur un grand site. Google Search Console a une sous-section “Signaux Web Essentiels” dans la section “Améliorations” dans la barre de navigation principale où vous pouvez voir le nombre de pages sur votre site affectées par chaque Core Web Vital.

Après avoir cliqué sur cette sous-section, vous verrez un rapport pour chaque problème Core Web Vital (sur mobile et sur ordinateur) où votre site peut être en difficulté.

Ainsi, vous verrez les cas de CLS de plus de 0,1et le nombre de pages sur votre site qui sont affectées par ce Core Web Vital particulier.

Les rapports “Signaux Web Essentiels” ne vous montreront pas toutes les pages que vous devez corriger. Franchement, ce serait une façon lente et douloureuse d’aborder tous les problèmes Web Vital que vous allez probablement avoir besoin de corriger les choses sur un niveau modélisé pour fixer plus d’une page à la fois.

Une liste de jusqu’à 20 pages similaires où ce problème se produit sera affiché. Chaque URL d’exemple vous montrera quelques pages similaires. Google utilise cette méthode pour mettre en évidence le fait que les mêmes problèmes trouvés sur votre page d’exemple se trouvent sur d’autres pages de votre site.

Par exemple, si vous avez un problème sur votre /blog/ et que le même problème se produit sur les pages de votre section /communiqués de presse/section, vous ne verrez que celui de ceux dans les URLs de l’exemple, mais l’autre s’affichera dans les détails de l’exemple.

Cela devrait vous suggérer que plus de pages dans /communiqués de presse/ auront besoin du même correctif.

Corriger vos Signaux Web Essentiels

 

Maintenant que vous comprenez mieux ce que chaque mesure Core Web Vitals mesure et comment elles représentent des points de douleur pour vos audiences qui essaient d’accéder à votre contenu et d’engager avec vos marques, il est temps de prendre des mesures pour améliorer ces mesures – mais surtout, améliorer votre engagement auprès de votre public.

Chaque site va être un peu unique. Il serait rare que deux sites distincts souffrent exactement des mêmes problèmes – il est donc important de vraiment creuser et analyser vos domaines individuellement pour hiérarchiser les mises à jour qui seront les plus bénéfiques.

Bien sûr, il y a des problèmes plus communs auxquels les sites Web font face, et par la suite, nous pouvons pointer vers des correctifs communs pour les problèmes auxquels vous pouvez faire face.

  1. Activités communes pour aborder le LCP :

    • Appliquer le chargement instantané avec le modèle PRPL
    • Optimiser votre chemin de rendu critique
    • Optimiser les fichiers CSS
    • Optimiser la taille et la compression des fichiers d’images
    • Optimiser ou supprimer les polices Web
    • Optimiser ou réduire votre JavaScript (pour les sites rendus par le client)
  2. Activités communes pour aborder le FID :

    • Réduire l’impact du code tiers
    • Réduire le temps d’exécution JavaScript
    • Minimiser le travail du thread principal
    • Gardez le nombre de demandes faible et les tailles de transfert petites
  3. Activités communes pour s’attaquer au CLS :

    • Inclure les attributs de taille (Hauteur et Largeur) sur vos images et éléments vidéo ou réserver l’espace avec des boîtes de ratio d’aspect CSS
    • Ne jamais insérer de contenu au-dessus du contenu existant, sauf en réponse à une interaction utilisateur
    • Utiliser des animations transformatrices au lieu d’animations de propriétés qui forcent les changements de mise en page

Source : Brightedge