Mise à jour de Google de mai 2021 : un examen plus approfondi de Core Web Vitals

MISE À JOUR : Le monde du marketing numérique est en constante évolution, mais ne vous inquiétez pas, nous sommes au top. Google a changé d'avis sur l'algorithme à venir.

Lisez les changements récents ici dans notre mise à jour, mais n'hésitez pas à lire ce blog aussi.

En mai 2021, Google introduira les métriques Core Web Vitals (CWV) pour faire partie de son algorithme de classement de recherche. Voici ce que vous devez savoir et faire avant…

Nous savons tous que les sites rapides sont importants. Ils créent une meilleure expérience utilisateur, entraînant des taux de conversion accrus et prennent déjà en compte le classement de la recherche mobile dans Google ainsi que d'autres mesures d'expérience de page telles que la convivialité mobile.

Mais Google ne s'arrête pas là. En mai 2020, ils nous ont parlé de Core Web Vitals et le 10 novembre 2020, ils ont annoncé qu'en mai 2021, Core Web Vitals serait incorporé en tant que signal de recherche dans l'algorithme de classement global.

En outre, ils prévoient de « tester un indicateur visuel qui met en évidence les pages dans les résultats de recherche qui offrent une excellente expérience de page ». Ainsi, non seulement nous avons une chance accrue d'obtenir des classements plus élevés grâce à l'optimisation CWV, mais nous avons également la perspective d'une augmentation des taux de clics à partir des pages de résultats des moteurs de recherche.

Agir maintenant pour auditer et résoudre tous les problèmes potentiels signalés avec ces nouvelles métriques CWV donnera à nos sites une meilleure chance d'être mieux classés par Google lorsque ce changement entrera en vigueur en 2021.

Mais d'abord, un récapitulatif...

Récapitulatif : que sont les Core Web Vitals ?

Core Web Vitals est un ensemble de 3 nouvelles mesures d'expérience de page qui entrent dans les scores de vitesse globale du site. Ces métriques jouent déjà un rôle de premier plan dans l'outil PageSpeed ​​Insights de Google PSI et la surveillance des performances de Lighthouse ailleurs.

Les nouvelles métriques CWV comprennent les éléments suivants :

La plus grande peinture à contenu (LCP)

Il s'agit du temps nécessaire avant que l'élément le plus grand au-dessus du pli soit rendu à l'utilisateur. Il représente 25 % du mécanisme de score de vitesse global et il est donc extrêmement important de rationaliser la livraison du plus gros article à 2,5 secondes ou moins sur mobile.

De nombreux facteurs contribuent à un LCP élevé, notamment la réactivité du serveur, les scripts et styles de blocage de rendu, la complexité des CSS, des polices et des images

Délai de première entrée (FID)

Cela mesure l'interactivité; dans quelle mesure la page est-elle réactive à l'entrée de l'utilisateur, par exemple via des tapotements ou des clics. La vitesse cible à laquelle le navigateur répond à la première entrée doit être de 100 ms ou moins.

Si le navigateur analyse ou exécute beaucoup de JavaScript pendant le chargement de la page, cela bloquera le processeur ou bloquera le « fil principal », ce qui rendra les appareils moins réactifs aux entrées. Un FID élevé est généralement un indicateur de JavaScript complexe. Il peut s'agir d'un seul script ou d'une fonction ou de plusieurs scripts.

Les mesures PSI existantes pour le délai d'interactivité et le temps de blocage total sont liées au FID et représentent collectivement 35 % des scores de vitesse globaux.

Décalage de mise en page cumulatif (CLS)

Il s'agit d'une mesure de la stabilité visuelle du contenu au-dessus du pli. Bien qu'il ne représente que 5% des scores de vitesse globaux, il vaut toujours la peine d'être pris en compte dans l'ensemble. Un CLS élevé peut souvent indiquer un ou plusieurs changements dans la mise en page visuelle pendant le chargement de la page, par exemple lorsque les bannières sont chargées en déplaçant le contenu de la page vers le bas.

Répartition du score de vitesse

Le diagramme ci-dessous montre une ventilation du score de vitesse global et le rôle que jouent ces nouvelles métriques CWV dans les scores GPSI.

Données source de la mise à jour du score Lighthouse

Bien que les métriques non CWV forment également le score global, y compris First Content Paint (FCP), Time to Interactive (TTI) et Total Blocking Time (TBT), se concentrer sur les trois métriques CWV aura un impact direct sur les autres. Un LCP rapide n'est par exemple pas possible sans un FCP rapide et les scores FID élevés sont directement impactés par le TBT et le TTI.

Conseils pour la plus grande optimisation de la peinture de contenu

La métrique LCP est composée de nombreux facteurs individuels et directement impactée par un FCP élevé. Si le FCP est signalé comme médiocre, vous pouvez commencer ici. Tout ce qui concerne la connectivité réseau, la réactivité du serveur, le temps jusqu'au premier octet TTFB et les fichiers bloquant le rendu affecteront tous la valeur FCP. Pour approfondir certaines de ces recommandations de vitesse de page plus génériques, consultez notre eBook sur la vitesse de page sur le sujet en plus des conseils spécifiques au LCP ci-dessous.

Si la valeur LCP est beaucoup plus élevée que FCP, alors nous devons chercher comment nous pouvons mieux rationaliser l'affichage de ce plus grand élément.

Déterminer le plus grand élément

La première chose que vous voudriez probablement faire est de déterminer quel est le plus grand élément. Le plus grand élément est basé sur la zone de pixels qui peut changer à différents points d'arrêt, de sorte qu'un balayage visuel peut ne pas nécessairement identifier le bon élément.

Dans PSI, il devrait y avoir un panneau « Largest Contentful Paint element » dans la section Diagnostic. Vous pouvez également afficher le LCP en survolant l'indicateur dans l'outil de surveillance des performances de Chrome, comme indiqué ci-dessous.

Sur le site Hallam dans l'exemple ci-dessus, le moniteur de performances affiche le LCP comme l'en-tête principal « Prospérer en ligne ». Idéalement, LCP devrait immédiatement suivre FCP comme dans cet exemple et s'il y a un écart entre les deux, nous devons essayer de comprendre pourquoi.

Les polices sont-elles optimisées ?

Si l'élément le plus grand au-dessus du pli est la typographie, nous devons nous assurer que la livraison des polices est aussi rationalisée que possible. Ceci comprend:

1. Utilisez l'affichage de la police CSS : swap; pour garantir un affichage immédiat des polices pendant le chargement du fichier de polices. Les polices Google et Typekit d'Adobe ont la possibilité de définir le paramètre « affichage » de la police.
2. Essayez d'héberger localement les fichiers de polices .woff et .woff2 sur le serveur au lieu d'effectuer des requêtes interdomaines vers des polices tierces. Google Fonts est assez rapide, les polices Typekit sont plus lentes et certaines fonderies de polices tierces peuvent être moins fiables.
3. Le préchargement des fichiers de polices peut aider. Les polices hébergées localement seront souvent incluses dans la feuille de style principale du site Web, mais cette feuille de style doit être téléchargée et analysée avant qu'une demande supplémentaire ne soit faite à la police qu'elle contient. Le préchargement indique au navigateur de commencer à télécharger la police plus tôt, sans attendre que le CSS soit analysé.
4. Utilisez preconnect et dns-prefetch pour les fonderies de polices tierces. Ces directives aideront à établir des connexions DNS, TLS et TCP entre des domaines tiers avant que la demande ne soit faite aux polices.
5. Incluez uniquement les fichiers de polices pour la typographie requis pour le dessus de l'écran pliable. Les éléments de police pour les bibliothèques d'icônes telles que Font Awesome sont notoirement lourds, mais les demandes à ces derniers (et à la bibliothèque d'icônes correspondante CSS) peuvent généralement être différées et chargées après l'élément <head>.
6. N'effectuez pas de requêtes interdomaines vers des fichiers de polices dans la feuille de style du site principal, car cela dépend de la connectivité et de la recherche supplémentaire d'un domaine tiers.
7. Pensez aux polices sécurisées pour le Web. Ceux-ci ne nécessitent aucune demande de fichiers de polices, bien qu'ils puissent être très limités en termes d'esthétique.

Les images sont-elles optimisées ?

Très souvent, l'élément le plus grand au-dessus du pli sera une image si importante pour garantir que les images sont optimisées. Ce qui suit est une bonne pratique en général, mais particulièrement importante pour l'élément LCP.

1. Utilisez le bon type de fichier image. Les images JPG doivent être utilisées pour les photographies, les SVG pour les graphiques vectoriels et les icônes ou les PNG pour les images non photographiques plus complexes et si la transparence est requise.
2. Assurez-vous que les images JPG sont enregistrées ou produites avec une qualité d'environ 50 à 60%. À ce niveau, il ne devrait pas y avoir de perte de qualité perceptible. Assurez-vous également que les métadonnées des images ont été supprimées.
3. Les plugins ou services de compression tels que tinypng.com peuvent optimiser automatiquement et en bloc les images et supprimer les métadonnées inutiles.
4. Les images doivent être de taille appropriée pour la zone dans laquelle elles s'affichent. N'exportez pas l'image de bureau de haute qualité sur un mobile.
5. Les images doivent être générées à l'aide de la balise <img> standard avec l'attribut 'srcset' pour les images réactives.
6. Sous le pli ou les images hors écran doivent utiliser l'attribut loading="lazy".
7. Utilisez le format de fichier image .web de nouvelle génération pour des taux de compression encore meilleurs. Cela peut facilement économiser 30% et dans de nombreux cas beaucoup plus.
8. Envisagez de précharger l'image la plus grande au-dessus de la ligne de flottaison pour lancer le téléchargement plus rapidement avant d'autres contenus potentiellement moins critiques.

Réduire les fichiers bloquant le rendu

Tout fichier JavaScript ou CSS chargé dans l'élément <head></head> est considéré comme bloquant le rendu car ces fichiers doivent être téléchargés avant que la page puisse commencer à s'afficher. Cela peut avoir un impact énorme sur les métriques FCP et LCP. Les fichiers de blocage de rendu dans la tête ne doivent être utilisés que s'ils sont essentiels pour l'affichage initial au-dessus du pli sur la page.

La suppression de tous les fichiers inutilisés dans <head>, le chargement de fichiers non critiques dans le pied de page ou la combinaison de plusieurs fichiers en moins de fichiers réduiront la quantité d'actifs bloquant le rendu.

Ne pas utiliser JavaScript pour afficher le LCP

Avant CWV, ce n'était pas grave. Il est courant que JavaScript soit utilisé pour animer ou afficher des éléments au-dessus du pli, comme avec du texte en fondu ou des carrousels de héros, souvent avec peu ou pas d'impact sur les scores de vitesse.

Si l'affichage du plus grand élément repose sur JavaScript, cela peut souvent entraîner un long délai car JavaScript doit être téléchargé, analysé et exécuté avant que l'élément n'apparaisse. Les fichiers JavaScript sont généralement (et à juste titre) chargés après l'élément <head> afin qu'ils ne "bloquent pas le rendu", mais cela signifie qu'ils peuvent toujours bloquer efficacement le rendu du LCP.

Jetez un œil à l'exemple ci-dessous (logo flou et titre modifié), il provient d'un site par ailleurs très bien noté dans PSI. Le LCP (le texte de l'en-tête principal) est plusieurs secondes plus éloigné du FCP, ce qui est dû à l'exigence de JavaScript (représenté par les bandes jaunes) de télécharger, d'analyser et d'exécuter avant que le texte ne puisse apparaître.

La décoloration du texte en elle-même peut également être un problème, provoquant un affichage retardé du plus grand élément.

Des techniques JavaScript telles que celle-ci peuvent immédiatement réduire les scores de vitesse globaux de 25% et ne doivent en aucun cas être utilisées pour entraver ou empêcher le chargement du plus grand élément.

Exécuter des scripts lors du chargement de la fenêtre

JavaScript est rarement requis (et ne devrait pas être requis) pour afficher le contenu critique au-dessus du pli, mais un problème courant que nous constatons est que les fonctions peuvent être déclenchées dès que le DOM est prêt. Dans le framework jQuery populaire, cela se fait via l'événement 'ready'. Google Tag Manager peut également déclencher des fonctions ou des « tags » prêts à l'emploi.

Envisagez de déclencher tout JavaScript non requis pour l'affichage critique du contenu sur l'événement de chargement de la fenêtre, après le chargement du contenu de la page principale pour éviter toute interférence potentielle avec le rendu du contenu au-dessus du pli et de l'élément LCP.

Basculer le LCP

Peu importe à quel point une image est optimisée et rationalisée, il faudra presque toujours plus de temps à télécharger et à afficher par rapport à un élément typographique. Bien qu'il soit tout à fait possible d'obtenir des scores LCP rapides pour les images, parfois un ajustement pour réduire le plus grand élément d'image afin qu'il soit plus petit que le plus grand élément de texte signifie que le texte peut être utilisé pour le LCP à la place.

Cela peut faire une grande différence pour les partitions, si la conception le permet, comme le montre l'exemple ci-dessous où le LCP a été basculé vers un élément de texte.

Conseils pour l'optimisation du délai de première entrée

Comme nous l'avons mentionné précédemment, FID mesure la réactivité de la page aux entrées de l'utilisateur. Il combine le Time To Interactive TTI et le Total Blocking Time TBT qui peuvent représenter jusqu'à 35% des scores de vitesse globaux.

Ces métriques sont principalement affectées par l'analyse et l'exécution des scripts lors du chargement de la page ; bloquant le fil principal du processeur et affectant potentiellement la réactivité de l'appareil, en particulier pour les smartphones bas de gamme.

Il est important de noter que les « Données de laboratoire » affichées dans PSI ne mesurent pas directement le FID. Cela est dû à la nature interactive de la mesure à partir de tapotements ou de clics par l'utilisateur qui est difficile à simuler. Au lieu de cela, elles sont collectées par des « données de terrain » ; mesures recueillies auprès d'utilisateurs réels sur une période de 28 jours sur la base du rapport Chrome User Experience CrUX.

En tant que tel, l'optimisation directe pour FID est un peu plus difficile, car nous ne pouvons rien changer et attendre 28 jours pour que davantage de données soient collectées. Nous devrions donc utiliser les métriques TTI et TBT dans les données de laboratoire pour cela à la place, car les temps bas pour ces métriques seront corrélés à un faible FID.

Alors, comment allons-nous optimiser ces mesures ?

Auditez votre JavaScript

JavaScript peut prendre toutes les formes et toutes les tailles et il n'est pas rare qu'une seule vidéo intégrée, un widget de chat, un script ReCaptcha ou une intégration HubSpot soit la seule cause derrière les métriques élevées FID, TTI et TBT.

Les panneaux de diagnostic de Page Speed ​​Insights sont un bon point de départ. La section "Réduire le travail du thread principal" vous indiquera combien de temps d'exécution est pris par JavaScript, la section "Réduire le temps d'exécution de JavaScript" indiquera quels fichiers ont des temps d'analyse et d'exécution élevés et "Réduire l'impact des tiers code' mettra en évidence et regroupera les scripts tiers à fort impact.

La capture d'écran ci-dessous montre un site qui souffre de plusieurs scripts lourds, avec une métrique Time to Interactive de 15 secondes. De nombreux scripts proviennent de tiers, notamment HubSpot et Vimeo.

Pour une analyse et une visualisation plus approfondies de l'impact de ces scripts sur le chargement de la page, l'outil de surveillance des performances de Chrome peut être un excellent moyen d'explorer les scripts et les fonctions déclenchés, l'impact relatif de ces scripts et à quel point de chargement de la page ces derniers de longs scripts sont exécutés.

L'exemple ci-dessous provient du même site et montre JavaScript représenté par les barres jaune, rose et orange, avec des barres plus longues montrant des tâches d'exécution plus longues. Lorsque nous cliquons sur ces tâches plus longues, nous pouvons voir que les scripts mis en évidence sont en corrélation avec les scripts volumineux mis en évidence par PSI ci-dessus.

Une fois que nous avons une meilleure idée des scripts qui ont un impact sur les performances, nous pouvons utiliser plusieurs techniques pour minimiser leur impact, comme indiqué ci-dessous.

Charger les scripts de manière asynchrone

JavaScript par défaut s'exécutera en séquence. S'il existe des scripts qui ne dépendent pas du chargement des autres, ces scripts doivent être chargés avec l'attribut 'async' afin qu'ils ne bloquent pas l'analyse et l'exécution d'autres scripts.

Charger JavaScript conditionnellement

Un problème commun que nous voyons sur de nombreux sites est que les scripts lourds sont chargés globalement ou sur des pages lorsqu'ils ne sont pas nécessaires. Si vous devez utiliser ReCaptcha, par exemple, pour aider à arrêter le spam sur les soumissions de formulaires, assurez-vous de ne charger les scripts que sur les pages contenant des formulaires.

Rationalisez les bundles JavaScript

Les bibliothèques JavaScript telles que jQuery UI ou Bootstrap sont souvent utilisées pour fournir des fonctionnalités et fonctions JavaScript supplémentaires. Si vous utilisez un bundle, assurez-vous d'inclure uniquement les fonctionnalités pertinentes dans le bundle pour éviter que JavaScript inutile ne soit téléchargé et analysé.

Scripts de chargement différé en cas de besoin

Même si JavaScript n'est chargé que sur les pages sur lesquelles il est nécessaire, le script lui-même n'a pas nécessairement besoin d'être analysé et exécuté pendant le chargement de la page ou l'événement de chargement de la fenêtre. Charger JavaScript uniquement lorsque cela est réellement nécessaire peut faire une énorme différence pour les métriques TTI, TBT et FID. Voici quelques exemples:

1. Les intégrations vidéo telles que YouTube et Vimeo ont généralement un impact élevé. Envisagez de ne charger ces scripts que lorsque vous cliquez sur une miniature de vidéo à la place.
2. Les intégrations de formulaires tiers telles que HubSpot peuvent être intensives. Si le formulaire apparaît dans un modal, ou en bas d'une page, pensez à charger ou à injecter le script requis lors du défilement ou de l'activation modale au lieu du chargement de la page.
3. Les widgets de chat en direct peuvent affecter les scores de vitesse globaux jusqu'à 35%. Envisagez de déplacer le widget de chat en direct vers une page de contact dédiée avec prise en charge du CTA global de « chat en direct », ou d'injecter le script de chat en direct uniquement lorsque vous cliquez sur un bouton « discuter avec nous ».
4. L'ajout de l'attribut 'loading="lazy" sur le contenu basé sur iFrame intégré peut aider, mais il s'agit d'une nouvelle fonctionnalité de navigateur et devra être testée en fonction de l'intégration iFrame utilisée.

Évaluer les outils de business intelligence

L'analyse du comportement des utilisateurs avec des outils tels que Hotjar ou des logiciels de test A/B tels que VWO est très importante pour la business intelligence et, dans de nombreux cas, leurs avantages l'emporteront sur l'impact sur la vitesse du site.

Cela dit, il vaut toujours la peine d'évaluer l'importance d'exécuter ces outils 24 heures sur 24, 7 jours sur 7, en fonction de la fréquence d'analyse des données. Les tests A/B doivent être désactivés si aucun test actif n'est en cours par exemple et les outils d'analyse comportementale tels que Hotjar peuvent être désactivés une fois que suffisamment de données ont été collectées et traitées.

Conseils pour l'optimisation du décalage de mise en page cumulatif

Le décalage de mise en page cumulatif (CLS) peut ne représenter que 5% des scores de vitesse globaux, mais reste néanmoins une partie importante de l'image globale, d'autant plus qu'une grande quantité d'éléments changeants lors du chargement de la page peut être une expérience choquante pour l'utilisateur.

Déterminer l'élément CLS

Parfois, il peut sembler évident quel ou quels éléments provoquent un changement dans le contenu, mais cela vaut toujours la peine de le vérifier via le panneau Layout Shift dans PSI, comme indiqué ci-dessous.

La métrique CLS doit être inférieure à 0,1, mais dans l'exemple ci-dessus, elle est dépassée de plus de 400 % et entraînera une baisse des scores de 5 %. S'il s'agit d'un problème mondial, c'est 5% sur chaque page.

Les éléments changeants doivent être identifiés et traités par ordre d'impact et peuvent inclure des éléments au-dessus et au-dessous du pli. Nous avons mis en évidence ci-dessous certaines des causes et des résolutions les plus courantes du changement de mise en page.

Attention aux animations

Il est assez courant que certaines techniques d'animation soient utilisées pour modifier la façon dont le contenu est présenté à l'utilisateur, par exemple en fondu ou en faisant glisser des images, du texte ou des panneaux de contenu lorsque l'utilisateur fait défiler une page. Bien que celles-ci puissent être esthétiques (selon la personne à qui vous demandez), il est important que ces techniques ne déplacent aucun contenu pendant le chargement de la page.

Si vous devez masquer puis masquer le contenu pour l'utilisateur, assurez-vous que la taille du conteneur ou la hauteur totale de la page ne change pas en fonction du contenu chargé. Le contenu peut être masqué (si nécessaire) à l'aide des règles de visibilité CSS plutôt que d'afficher : aucune ; ce qui préservera la quantité sous-jacente d'espace dont il a besoin.

Spécifiez les dimensions de l'image

Si la balise <img> n'a pas d'attribut largeur et hauteur défini, ou si CSS n'est pas utilisé pour définir les dimensions ou le rapport de l'image, les navigateurs devront d'abord télécharger l'image avant de pouvoir déterminer la zone de pixels dont elle a besoin. Cela peut provoquer un décalage de tout contenu rendu sous l'image, au fur et à mesure que l'image est chargée.

Spécifier la largeur et la hauteur de l'image, ou définir les dimensions ou le rapport de l'image (ou du conteneur parent) dans CSS avant le téléchargement de l'image garantira que les navigateurs connaîtront la zone dans laquelle l'image doit s'afficher et éviteront une mise en page potentielle changement.

Bannières

Les publicités, les barres de loi sur les cookies ou toute autre information utilisée pour afficher des informations importantes dans une bannière sont probablement l'une des causes les plus courantes d'un CLS élevé.

Il est courant que le contenu de la bannière soit chargé à partir d'une source de données externe ou via JavaScript à partir du même site, ce qui signifie que la taille du conteneur de la bannière peut ne pas être possible de calculer tant que le contenu n'a pas été chargé. Lorsque cela se produit, le contenu sous la bannière se déplacera vers le bas une fois que le contenu de la bannière sera chargé et affiché pour l'utilisateur.

Il y a plusieurs résolutions à cela :

1. Définissez une hauteur minimale pour la bannière ou le conteneur de bannière dans CSS afin que le navigateur puisse efficacement afficher un espace réservé. Bien que cela puisse être problématique si la quantité de contenu est dynamique et inconnue.
2. Absolument ou fixez la position de la bannière en haut ou en bas de l'écran. Pour les bannières qui peuvent être fermées ou supprimées, il s'agit d'une bonne considération car les éléments fixes n'affecteront pas le positionnement des autres éléments.
3. Regardez si possible le rendu côté serveur du contenu de la bannière, ce qui signifie que le contenu et les dimensions de la bannière peuvent être chargés à l'avance avant d'atteindre l'utilisateur.

Résumé

Espérons que vous trouverez certaines des techniques décrites ci-dessus utiles pour diagnostiquer et résoudre les problèmes de performances liés aux nouveaux Core Web Vitals de Google. Au cours des derniers mois chez Hallam, nous avons aidé un certain nombre de clients à améliorer les performances de leur site Web à la fois en termes de nos audits de vitesse et d'améliorations directes apportées par notre équipe de développement.

Si vous avez trouvé cet article utile, vous pouvez également consulter notre eBook sur les performances du site Web, qui approfondit certaines des recommandations les plus génériques concernant la vitesse de la page dont toute personne créant ou gérant un site Web peut bénéficier.