Home Articles techniques Le cœur des Web Vitals
Applications

About The Author

Outline

Introduction

Depuis son introduction en mai 2020, la suite Core Web Vitals (CWV) de Google est devenue une mesure importante pour mesurer les performances des sites Web. Étant donné que Google considère ces valeurs comme faisant partie de son algorithme de classement des pages, maximiser les performances de votre site Web en termes de CWV améliore non seulement l’expérience de vos utilisateurs, mais améliore également votre classement dans les moteurs de recherche. Cet article explorera des conseils et des techniques pour vous aider à améliorer vos scores de page, augmenter la satisfaction des utilisateurs et augmenter vos résultats.

Que sont les Core Web Vitals ?

Comme tant d’autres choses en technologie, les Web Vitals de Google sont un essaim d’acronymes à trois lettres, chacun représentant un aspect mesurable de la performance d’un site Web. Pour préparer le terrain, définissons les trois indicateurs clés qui définissent les paramètres vitaux Web de base :

Peinture la plus complète

Plus grande peinture de contention (LCP) : mesure la vitesse de chargement perçue en se concentrant sur le temps nécessaire au chargement du contenu visible au-dessus du pli. Pour offrir une expérience utilisateur idéale, le LCP doit être déclenché dans les 2,5 secondes de la chronologie de chargement de la page.

Délai de première entrée

Premier délai d’entrée (FID) : mesure la réactivité de la page en mesurant le délai entre les actions de l’utilisateur et la réponse de la page. Pour offrir une expérience utilisateur idéale, les pages doivent avoir un FID de 100 millisecondes ou moins.

Décalage de mise en page cumulé

Décalage de mise en page cumulatif (CLS) : mesure la stabilité visuelle à l’aide d’une mesure composite des décalages de mise en page sur la page lors du rendu. Pour offrir une expérience utilisateur idéale, les pages doivent maintenir un CLS de 0,1 ou moins ; tout ce qui se situe entre 0,1 et 0,25 est considéré comme modéré et supérieur à 0,25 est médiocre.

… et pourquoi sont-ils importants?

Pour de nombreuses entreprises, la performance du site Web a une corrélation directe avec le succès de l’entreprise. La recherche indique que les sites Web avec des scores CWV réussis peuvent bénéficier d’une visibilité jusqu’à 37 % plus importante dans les résultats de recherche par rapport aux pages qui n’en ont pas (Beus) ; et que l’amélioration des scores CWV peut augmenter à la fois les revenus par visiteur et le taux de conversion (Duong et al.).

Lorsque vous travaillez avec Akira, Une boutique de mode pour femmes, Edgio a pu améliorer les CWV du site, portant les temps de chargement de la première page de 5 secondes à ~1 seconde, améliorant les mesures CWV et offrant finalement une augmentation de +30% du trafic organique, une amélioration de +61% des initiations de caisse et une augmentation de 37% du taux de conversion.

En termes simples, les sites Web plus rapides permettent de meilleurs classements SEO et des utilisateurs plus heureux – en particulier dans le contexte des sites Web de commerce électronique ; ces derniers se combinent pour réduire les taux de rebond et augmenter les conversions.

Alors, comment pouvons-nous les améliorer?

Délai de première entrée

Commençons par le fruit à faible hauteur : First Input Delay. La bonne nouvelle est que les sites Web ont des scores FID plus souvent qu’autrement, ce qui est génial à voir! Si, cependant, ce n’est pas le cas, souvent, le coupable est les scripts tiers chargés tôt dans le cycle de vie du site Web, ce qui peut bloquer l’exécution du thread principal nécessaire pour recevoir les entrées de l’utilisateur. Les outils qui capturent les erreurs et effectuent des enregistrements d’écran sont les meilleurs candidats pour un examen plus approfondi.

En fait, tout ce qui bloque le thread d’exécution principal peut contribuer à de mauvaises performances FID. Gardez un œil attentif sur les tâches JavaScript gourmandes en ressources ou de longue durée, et envisagez de refactoriser du code non lié à l’interface utilisateur à un travailleur Web, ainsi que d’utiliser des techniques de chargement paresseux et de division de code pour vous assurer que seul le JavaScript requis est chargé et seulement quand il est nécessaire.

De plus, bien qu’il ne s’agisse pas techniquement d’un élément essentiel des CWV, il convient de mentionner une autre mesure connexe : interaction to Next Paint (INP). INP mesure le temps entre l’interaction avec une page et la mise à jour ultérieure de la page reflétant cette interaction. Alors que INP et FID mesurent tous les deux la réactivité globale des pages, INP se préoccupe de toutes les interactions des pages plutôt que de la première interaction, afin de s’assurer que la page reste réactive tout au long de la session, et pas seulement des interactions initiales. INP suit les pires performances d’interaction au cours de l’expérience d’un utilisateur et le signale à Crux. Il est très probable que bientôt INP remplacera FID comme mesure de la réactivité de la page, il vaut donc la peine de garder un œil dessus.

Peinture la plus complète

Sans doute la mesure la plus importante et la plus impactante pour les performances des pages est LCP. De manière assez prévisible, l’exemple le plus courant de la plus grande peinture Contentful est une image « héros » – une grande image ou vidéo, occupant généralement toute la largeur de la fenêtre d’affichage au-dessus du « pli ». Bien que les techniques d’optimisation de cet élément soient les mêmes que pour toute autre ressource de page, le temps nécessaire pour que cette ressource s’affiche est d’une importance capitale car c’est le premier élément principal qu’un utilisateur expérimentera.

En attente dans la file d’attente
La décomposition de la synchronisation de la requête pour l’élément LCP est extrêmement utile pour optimiser ses performances. Toute demande faite par un navigateur commence par la file d’attente. Chaque milliseconde de requêtes LCP passées dans la file d’attente est une milliseconde qui contribuera au score LCP, donc si vous trouvez que ces éléments passent une quantité disproportionnée de temps à languir dans la file d’attente du navigateur, examinez ce qui est demandé à l’avance et pourquoi, et prendre des mesures pour hiérarchiser les ressources LCP. Peut-être que les ressources sont en dessous du pli, ou d’autres scripts qui peuvent être lazy-loads ou autrement différés. L’ordre des opérations est essentiel.

En attente sur le serveur
Après avoir lancé la requête réseau, le client navigateur doit attendre que le serveur reçoive, traite et réponde à cette requête. Cette métrique est appelée temps jusqu’au premier octet (TTFB). Si le serveur est lent à répondre à la requête, votre score LCP en souffrira. C’est l’un des domaines dans lesquels un CDN peut avoir un impact significatif sur l’amélioration de la vitesse, car les CDN peuvent conserver une copie en cache de la ressource dans un emplacement géographiquement proche de vos utilisateurs finaux et répondre avec cette ressource plus rapidement qu’un seul serveur d’applications. Parmi les autres aspects importants de l’utilisation d’un CDN, citons les WAF de sécurité intégrés et la capacité à répondre aux pics de trafic importants. Si vous optez pour la vitesse, vous devriez utiliser un CDN.

Large sur le fil
À ce stade, espérons-le, le navigateur demandera les ressources LCP tôt dans le cycle de vie de la page, et le serveur devrait y répondre rapidement. L’élément suivant à considérer est la taille globale de la ressource demandée. Chaque octet qui doit voyager « sur le fil » vers le navigateur prendra un certain temps, et plus il y aura de ces octets, plus il faudra de temps pour que la requête se termine. Il faut donc veiller à ce que les ressources soient aussi limitées que raisonnablement possible afin de réduire au minimum le temps consacré à leur transfert. Cela peut inclure l’utilisation de services d’optimisation d’image et d’hébergement tierces parties tels que kraken.io ou imgix.com, qui peuvent à la fois optimiser et servir des fichiers multimédias dans des formats « NextGen » tels que WebP, réduisant encore la taille.

Aidez le navigateur à sortir
En plus des optimisations de taille, pensez à utiliser <des balises d’image> , qui permettront au navigateur de choisir la bonne ressource à demander pour l’appareil de manière plus intelligente. Un navigateur de bureau peut avoir de grandes étendues d’écran pour afficher des images de plus haute résolution ; cependant, ces mêmes ressources encombrent un appareil mobile avec un écran plus petit. En utilisant des ressources optimisées et des requêtes CSS media, vous pouvez vous assurer que le navigateur demande la bonne ressource pour son type de périphérique et réduire le temps passé à transférer des octets du serveur au client.

De plus, vous pouvez donner un coup de main au navigateur en lui demandant de précharger les ressources LCP et en spécifiant une priorité de récupération. Ceux-ci donneront au navigateur des indices pour prioriser les ressources clés avant celles qui sont moins critiques. Plus les choses arrivent rapidement au navigateur, plus elles peuvent être rendues rapidement, et plus le LCP se produit rapidement, mieux c’est.

Décalage de mise en page cumulé

Nous le voyons tout le temps. Après avoir envoyé votre navigateur pour récupérer un site Web, la page commence à se charger; pendant que la page se développe, vous voyez la pièce qui vous intéresse et vous déplacez pour cliquer dessus quand soudainement toute la page change et le lien que vous pensiez sur le point de cliquer est soudainement ailleurs! Ce phénomène est appelé décalage de disposition. C’est ennuyeux pour tout le monde, généralement auto-infligé, et nous devrions nous efforcer de le minimiser pour le bien de l’humanité.

Les suspects habituels
Les coupables typiques des scores CLS plus élevés sont :

  • Barres de coupe collantes
  • Bannières promo ou « héros » chargées et rendues côté client
  • Bulletin d’information, coupon et avis GPDR
  • Autres intégrations tierces parties injectées dynamiquement dans la page

Définissez des limites
Vous vous souvenez de l’ <élément d’image> que nous avons mentionné lors de la discussion sur LCP ? N’oubliez pas d’ajouter des dimensions aux différents éléments qu’il contient. Omettre ces valeurs vous permet de sortir du siège du conducteur lorsque vous dirigez le navigateur sur la façon de rendre ces éléments. En définissant les dimensions, le navigateur peut mettre de côté la quantité correcte d’espace dans lequel l’image sera peinte, réduisant ainsi le décalage.

Il en va de même pour tout contenu qui pourrait être ajouté dynamiquement à la page. Les publicités, <iframe>ou tout autre contenu ajouté dynamiquement peuvent contribuer à CLS. Le contenu de la page sera moins décalé en réservant de l’espace pour ces éléments à l’avance. Évitez également d’ajouter le contenu au-dessus du contenu de la page existante, car cela provoquerait le décalage de la page entière en dessous.

Aider le navigateur à se tailler l’espace à l’avance réduira le CLS, mais peut se faire au détriment de l’expérience globale de l’utilisateur, car l’utilisateur attend que ces parties de la page autrement vierge soient remplies de contenu utile. En tant que terrain d’entente, la mise en œuvre de squelettes de chargement d’éléments peut être une technique utile pour communiquer à l’utilisateur qu’il y a plus à venir, donnant l’impression d’une expérience plus rapide tandis que le navigateur fait le reste du travail lourd pour coordonner le contenu de la page supplémentaire. Qui plus est, ceux-ci peuvent et doivent être implémentés en utilisant des animations CSS plutôt que des GIF animés, ce qui signifie que seulement quelques lignes de CSS peuvent être utilisées pour implémenter cette technique sur l’ensemble de votre site Web.

Conclusion

À première vue, Core Web Vitas peut sembler être les derniers morceaux de l’algorithme légendaire et ombragé de Google pour déterminer le classement de page dans leurs résultats de recherche – et dans une certaine mesure, cela pourrait être correct. Cependant, plus que cela, les Core Web Vitals représentent un cadre plus concret pour mesurer les performances des pages et établir une base de référence pour décrire les choses qui comptent en termes d’expérience utilisateur. Bien qu’elles ne soient pas exhaustives, les techniques susmentionnées devraient vous aider à prendre une longueur d’avance lors du dépannage et de l’optimisation des performances de votre site Web, ce qui, espérons-le, entraînera des améliorations dans l’expérience utilisateur, le classement de page et les revenus.