Voici une bonne nouvelle pour les webmasters et les développeurs d’applications web. Dans le rapport sur les Core Web Vitals sur Google Search Console (née Google Webmaster Tools), il est désormais possible d’avoir des exemples de liens pour les problèmes détectés par Google.
Jusqu’à présent, le rapport sur les Core Web Vitals des pages web sur GSC ne permettait de savoir que deux informations: la présence ou non de pages souffrant d’un problème de performance et, sommairement, le nombre de ces pages.
Bien que ces informations soient importantes, elles ne permettent pas une identification rapide du ou des problèmes à l’origine des faibles performances techniques. Plus maintenant. La nouvelle mise à jour permet aux utilisateurs de l’outil de Google de visualiser une liste d’exemples de liens touchés. Cela offre la possibilité d’investiguer en profondeur le problème et, potentiellement, de le résoudre une fois pour toutes.
Core Web Vitals est une énième initiative de Google visant à améliorer la vitesse de chargement et l’expérience utilisateur (UX) de tous les sites Internet. Bien que ce pari semble futuriste, c’est loin d’être le premier dessein de Google dans ce sens. À cela s’ajoute PageSpeed Insights, Mobile-Friendly Test, Lighthouse, entre autres, et les mouvements plus généraux – le format AMP, le Chrome UX Report et le site web.dev) que Google a créés et promus ces dernières années.
Core Web Vitals cherche à établir des critères simples et unifiés sur ce qu’est une bonne expérience web.
D’après l’annonce officielle de Core Web Vitals en 2020, Google était conscient que, jusqu’à présent, il avait travaillé avec un nombre excédent de paramètres. Il n’était pas évident pour quelqu’un ayant peu de connaissances techniques de comprendre en un coup d’œil où se situaient exactement les problèmes d’UX et d’optimisation de performance Web Front-End Optimization (WPO), et comment les résoudre.
C’est là qu’est né le Core Web Vitals, qui signifie littéralement Signaux web essentiels – interprétés comme un sous-ensemble d’éléments vitaux d’un site/page web.
Largest Contentful Paint, LCP
L’indicateur LCP mesure le temps de chargement du contenu, marque le moment exact où le plus grand élément de contenu – image, vidéo, bloc de texte – au-dessus du pli (ce que vous voyez sans défiler vers le bas) est entièrement chargé. Un bon LCP ne dure pas plus de 2,5 secondes. Compte tenu des causes d’un mauvais indicateur LCP, voici nos recommandations techniques sur la manière d’optimiser le LCP d’un site Internet.
First Input Delay, FID
Basé sur le framework RAIL (Response Animation Idle Load), le métrique First Input Delay ou « délai de première entrée » mesure la réactivité de la page web. Explicitement, c’est le temps qui s’écoule entre le moment où l’utilisateur effectue une action, à l’instar d’un clic, et celui où le navigateur répond à cette interaction.
Vous avez sans doute fait l’expérience de cliquer et de voir la page se charger jusqu’à ce qu’elle vous montre le résultat de cette action.
Un bon FID doit répondre en moins de 0,1 seconde, soit à 100 millisecondes. Pour y parvenir, évitez à tout prix d’utiliser Web Worker, un script JS indépendant des autres scripts, exécuté en arrière-plan d’une page HTML.
Cumulative Layout Shift, CLS
Le Cumulative Layout Shift ou «décalage cumulatif de mise en page» mesure la stabilité visuelle. Souvent, les éléments d’une page se déplacent au fur et à mesure que le contenu se charge et s’affiche sur l’écran – une expérience assez lassante et qui conduit généralement à de nombreux clics au mauvais endroit, ce qui gâche clairement l’expérience de navigation. Les éléments du temps de chargement des pages tels que content-paint et le time-to-interactive ont déjà été largement mesurés avec des outils comme PageSpeed Insights, mais pas le Cumulative Layout Shift. En fait, cette métrique CLS quantifie la fréquence et l’ampleur avec lesquelles ces changements se produisent sur une page.
