Il s’agit d’une mise à jour majeure de l’algorithme Google 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.
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 à HTTPS (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 Core Web Vitals, 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 ».
- 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 SEO & Dev), 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. - 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. - 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 Google Search 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.
- 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)
- Appliquer le chargement instantané avec le modèle PRPL
- 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
- Réduire l’impact du code tiers
- 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
- 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
Source : Brightedge
