Google a récemment annoncé que les changements à venir de la console de recherche en incorporant Core Web Vitals comme nouvelles mesures qui élargissent la façon dont Google mesure la vitesse et la performance des sites Web. Avec cette annonce, Google a fourni des informations sur un calendrier de 6 mois dans lequel ces mesures seraient contrôlées avant d’être utilisées dans le cadre du classement des recherches. Chaque fois que Google apporte des modifications de ce type, les éditeurs se demandent probablement : “Comment puis-je optimiser les principaux éléments vitaux du web ?”
Ces nouvelles mesures se trouvent dans Console de recherche Google. Ce qui était auparavant le “Rapport de vitesse” est maintenant l’onglet “Essentiels du Web”. Les données sont tirées du rapport Chrome UX (également connu sous le nom de CrUX). Ci-dessous, nous allons vous montrer comment optimiser les métriques de Core Web Vitals.
Sommaire
Quelles sont les mesures essentielles du Web ?
Les “Core Web Vitals” sont un ensemble de mesures liées à la vitesse, la réactivité et la stabilité visuelle, pour aider les propriétaires de sites à mesurer l’expérience des utilisateurs sur le web. Ils ont été introduits par l’équipe Chrome de Google.
Les trois facteurs qui composent les Core Web Vitals sont Loading, Interactivity, and Visual Stability. Mais quelles mesures comprennent ces facteurs ?
Chargement : Largest Contentful Paint (LCP) Interactivité : First Input Delay (FID) Stabilité visuelle : Cumulative Layout Shift (CLS)
Certaines de ces mesures de performance sont communes aux éditeurs, comme le délai de première entrée (First Input Delay – FID). Nous abordons cette mesure dans notre article sur les statistiques de vitesse moyenne des pages pour 2020. Cependant, des mesures comme la plus grande peinture concurrente (LCP) et le décalage cumulatif de la mise en page (CLS) ont été essentiellement inventées et créées par Google. Il est important de savoir ce que ces mesures signifient réellement afin d’optimiser et de comprendre quand ces mesures sont importantes et quand elles ne le sont pas.
Important : The Core Web Vitals est une nouvelle méthode pour mesurer les performances d’un site web, et est beaucoup plus nuancée que simplement “rapide ou lent”, et comprend des mesures largement inventées par Google qui peuvent ne pas refléter l’expérience réelle des utilisateurs.
Qu’est-ce que le CLS (Cumulative Layout Shift) ?
CLS (Cumulative Layout Shift) est une mesure de chargement de site web pour mesurer la stabilité visuelle. Il vise à quantifier la fréquence à laquelle les utilisateurs subissent des changements de mise en page inattendus.
Ci-dessous, un exemple de page qui a probablement un CLS élevé. L’utilisateur place son curseur sur la sélection “Non, y retourner”, et juste avant de cliquer, la mise en page change, et “Oui, passez ma commande” est accidentellement choisi. L’expérience de l’utilisateur est donc médiocre.
Un mouvement inattendu du contenu de la page se produit généralement parce que les ressources sont chargées de manière asynchrone ou que des éléments DOM sont ajoutés dynamiquement à la page au-dessus du contenu existant. –Web.Dev
Ce qui pourrait causer un taux élevé de CLS:
Image ou vidéo de taille inconnue
Rendu des polices
Publicités de tiers qui redimensionnent dynamiquement
L’un des grands problèmes est qu’un site web peut avoir une apparence et un comportement différents pour les utilisateurs et les développeurs. Les images et autres éléments sont souvent déjà dans le cache du navigateur du développeur, et les appels d’API qui s’exécutent localement sont souvent si rapides que le retard ou les décalages ne sont pas perceptibles.
Ainsi, aux yeux de Google, un CLS faible permet de s’assurer que la page fonctionne correctement pour les utilisateurs. Leur bonne portée est inférieure à .1s.
Qu’est-ce que le délai de la première entrée du FID ?
Le délai de première saisie (FID) mesure le temps entre le moment où un utilisateur interagit pour la première fois avec votre site (c’est-à-dire lorsqu’il clique sur quelque chose) et le moment où le navigateur est capable de répondre à l’interaction.
Pour être classés dans la catégorie “bon”, les éditeurs doivent s’efforcer d’avoir un FID inférieur à 100 millisecondes. Le FID est considéré ici comme UX (user experience) car il peut refléter la rapidité avec laquelle le contenu dont un éditeur se soucie est immédiatement accessible sur demande. Si vous êtes un site WordPress, les augmentations de FID proviennent probablement de vos plugins. Si vous avez l’habitude d’ajouter des éléments dans la “tête” de votre site web, et si ces éléments font beaucoup d’appels Javascript externes, vous pourriez ralentir considérablement le FID. Pour les utilisateurs de WordPress, ce conseil vaut également pour les plugins d’optimisation de la vitesse. Certains éditeurs utilisent non seulement un mais plusieurs plugins d’optimisation en même temps exactement. Ces plugins effectuent souvent des appels externes qui peuvent avoir l’effet inverse et augmenter le FID et ralentir votre site web.
Tout outil ou logiciel d’optimisation de la vitesse pourrait potentiellement avoir un impact sur le FID, ou sur notre prochaine métrique LPC, s’il nécessite l’exécution de nombreux javascript pour son exécution. Si les outils sont fournis via un plugin ou en ajoutant un extrait de code dans l’en-tête de votre site web, il est utile d’évaluer dans quelle mesure ces outils peuvent réellement nuire à vos scores FID ou LCP.
“Si les outils sont fournis via un plugin ou en ajoutant un extrait de code dans l’en-tête de votre site web, il est utile d’évaluer dans quelle mesure ces outils peuvent réellement nuire à vos scores FID ou LCP.”
Qu’est-ce que le LCP (Largest Contentful Paint) ?
LCP mesure la vitesse de chargement “perçue” par le visiteur. Elle était – et est sans doute toujours – calculée au mieux par en regardant DOM Interactive, mais maintenant Google regarde cette interaction un peu différemment.
La plupart des impacts de cette mesure se situent au-dessus des images, lecteurs vidéo et autres médias qui prennent du temps à charger avant que la partie de la page que l’utilisateur voit et avec laquelle il interagit ne lui soit immédiatement accessible. Ces derniers doivent se charger rapidement et dans un premier temps. Google veut donc s’assurer que tout ce qu’un utilisateur va voir lorsqu’il atterrit sur le site (au-dessus du pli) est visible rapidement et ne saute pas partout. Si vous avez des widgets média ou tout ce qui “flotte” sur la page, cela pourrait avoir un impact négatif sur cette mesure. Pour optimiser cela, voici quelques éléments à prendre en compte:
Barre d’inscription à la newsletter ou à l’abonnement flottante
G widgets flottants des médias sociaux
Icônes de médias sociaux qui se chargent au-dessus du pli pour le partage d’articles
Bulletin d’information, login ou widgets qui se chargent dans la fenêtre de visualisation d’un article par le visiteur
Vidéos qui se chargent au-dessus du pli (ci-dessous nous donnons des options pour cela)
Images au-dessus du pli (ci-dessous nous donnons des options pour cela)
Boîtes d’auteur qui sont auto-injectées avec des images sur la page
Comment le LCP diffère-t-il du FCP (First Contentful Paint) ?
LCP = Tient compte de choses comme les médias/vidéo. Quand l’utilisateur voit-il à quoi va ressembler la page actuelle ? Même si elle va charger d’autres choses encore en arrière-plan. FCP = Quand l’utilisateur voit-il votre contenu pour la première fois ? Ne charge pas le menu, ne voit pas de contenu vide mais quelle est la première fois qu’un utilisateur voit votre contenu.
Sur Google PageSpeed Insights, si vous lancez une URL, vous verrez un exemple du FID et du LCP. Vous pouvez voir un espace blanc de l’image ci-dessous, ce qui signifie que le contenu ne sautera pas partout lorsque l’image se chargera complètement.
Comment accélérer le CLS
La meilleure façon d’accélérer le CLS est de charger paresseusement les images et les publicités. Mais quand vous le faites, vous voulez vous assurer que les “pixels” pour l’emplacement de ces éléments sont définis.
Par exemple : Au fur et à mesure que le contenu se charge dans le GIF ci-dessous, tous les emplacements pour les publicités et les images sont déjà définis. Si une image ne s’est pas encore chargée parce que nous défilement très rapide, elle ne se déplace pas. Ce serait juste un espace blanc, vide, jusqu’à ce que vous puissiez finalement charger l’image.
Ce que vous ne voulez pas maintenant, c’est avoir ces images, publicités ou vidéos, chargement après coup. Donc si vous chargez paresseusement, assurez-vous d’avoir l’espace disponible, pour que votre contenu ne saute pas partout. Il existe un guide complet en ligne avec plusieurs codes CSS et Javascript pour vous aider à formater correctement vos images et autres contenus afin qu’ils se chargent en douceur lorsque l’utilisateur fait défiler les pages. Voici un code Javascript qui vous permet d’envelopper vos images avec suffisamment de rembourrage pour éviter les sauts : .wrapper {
position : relative ;
hauteur : 0 ;
/* La formule est : (hauteur / largeur * 100%) */
dessus du rembourrage : calc(360 / 360 * 100%) ;
}.wrapper__img {
position : absolue ;
haut : 0 ;
gauche : 0 ;
largeur maximale : 100% ;
hauteur : auto ;
} De plus, si vous utilisez Ad Tester, le testeur d’annonces d’Ezoic, les annonces qui apparaissent sur votre site web sont déjà correctement rembourrées de sorte que le contenu de votre site ne saute pas aux yeux de l’utilisateur une fois qu’il défile. Souvenez-vous en : Plus l’expérience de l’utilisateur est bonne, plus vos éléments vitaux du Web seront bons.
Comment améliorer le LCP
Une stratégie utile pour améliorer le LCP en dehors d’un chargement paresseux est d’essayer de charger des aperçus de vidéos sous forme de vignettes au lieu de vidéos complètes sur votre page. Vous trouverez des informations sur comment faire ici. Si vous utilisez WordPress, il existe un certain nombre d’outils et de plugins qui vous permettent de charger les iframes de YouTube sous forme d’image “d’aperçu” et l’utilisateur doit cliquer pour charger, au lieu de charger la vidéo lors du chargement de la page. Il existe également des fonctionnalités natives pour cela dans WordPress.
Comment empêcher le JavaScript d’augmenter le temps du FID
Le moyen le plus simple d’empêcher le JavaScript d’augmenter le temps de chargement du FID est de veiller à ajouter le moins de Javascript possible dans la tête de votre site web qui retarde quoi que ce soit du chargement au visiteur. Cela signifie qu’il faut évaluer tous les scripts ajoutés en tête de votre site web et tous les plugins actuellement utilisés si vous êtes un site web WordPress. Plus le javascript est inutile, plus vous pouvez le supprimer de votre site web, mieux c’est. Il vaut la peine de regarder le code de votre site web ou la liste des plugins WordPress pour voir si certains d’entre eux pourraient être désactivés ou reportés afin qu’ils ne soient actifs que sur les pages qu’ils utilisent.
Quelle est l’importance des éléments vitaux du Web pour les classements ?
Pour être réaliste, la chose la plus importante pour Google est que le chercheur obtienne un bon résultat de recherche. C’est le signal de classement primordial de Google, la “satisfaction de la recherche”. L’UX pour Google est différente de l’UX pour un éditeur. Une petite partie de ces données peut inclure l’UX du site web sur lequel le visiteur atterrit, et c’est pourquoi Google va commencer à utiliser Core Web Vitals comme un moyen de comprendre quels sites pourraient le faire mieux que d’autres.
Google utilisera ces données lorsqu’il tentera d’évaluer deux résultats très similaires. Si toutes les autres choses sont égales en termes de contenu, Google utilisera probablement quelque chose comme le Core Web Vitals pour obtenir une détermination ultime.
Vous pouvez considérer cela comme un bris d’égalité. Qu’est-ce qui est le mieux : le résultat #7 ou 8 ? C’est très probablement dans ce type de situation que Google pourrait appliquer les Éléments vitaux du Web pour modifier le classement des résultats de recherche.
L’amélioration des éléments vitaux du Web de base favorisera-t-il le référencement ?
Google prétend que certains des moyens d’améliorer les éléments vitaux du Web de base sont de :
Réduire la taille de votre page à moins de 500KB.
Limiter le nombre de pages ressources à 50.
Envisager l’utilisation de l’AMP.
Les éditeurs intéressés par Google AMP l’ont probablement déjà exploré. Mais il est intéressant de noter que Google vante sa propre création, AMP, comme une solution à un nouvel ensemble de mesures qu’il a lui-même créé. Voilà la vérité : ne vous focalisez pas trop sur ces mesures. Mais essayez de réduire autant que possible la taille de votre site web. Si vous utilisez un plugin pour la modification CSS, un autre pour la compression des images et un autre pour la vitesse du site, essayez d’en trouver un qui fait tout, comme l’application Site Speed Accelerator d’Ezoic. Le plus important est de se concentrer sur la construction d’un meilleur site web et d’offrir une meilleure expérience à l’utilisateur. Cela éclipsera tout ce sur quoi vous travaillez pour améliorer ces mesures.
Souvenez-vous : concentrez-vous sur votre contenu. Si vous passez plus de temps sur ces éléments vitaux du Web que sur votre contenu, vous allez perdre votre temps et probablement faire plus de mal que de bien.
Avez-vous des questions sur les éléments vitaux du Web de Google et sur la manière de les optimiser ? Faites-le moi savoir dans les commentaires.
