Les Core Web Vitals (indicateurs liés à la performance des pages Web) dont le déploiement était initialement prévu en Mai 2021, ne seront déployés qu’à partir de la mi-juin comme critères de classement des algorithmes de Google. Bien que l’impact ne soit pas trop important parmi les multiples critères de positionnement, il convient malgré tout de s’y intéresser de près, ne serait-ce que par rapport à l’impact côté utilisateur. Après avoir passé en revue le LCP (Largest Contentful Paint) et le CLS (Cumulative Layout Shift) dans les articles précédents, nous allons maintenant détailler le FID (First Input Delay), qui correspond au temps que mettra une page à répondre, après l’action d’un utilisateur.

Principe du FID

Le FID est une métrique orientée utilisateur qui mesure le temps entre le moment où un utilisateur interagit pour la première fois avec une page (exe : clic sur un lien, ou autre action contrôlée par Javascript) et le temps que mettra le navigateur à traiter les évènements à la suite de cette interaction. Un bon FID doit être inférieur à 100 ms.

Echelle de mesure du score CLS

Là où le FCP (First Contentful Paint) est important car il permet de mesurer la vitesse à laquelle les premiers pixels seront dessinés à l’écran de l’utilisateur, le FID l’est tout autant car il mesure la réactivité d’une page quand les utilisateurs souhaiteront interagir avec les premiers éléments qui auront été dessinés sur leur écran.

Qui n’a jamais été frustré lors du chargement d’une page qui ne répondait pas immédiatement, alors que vous essayez d’interagir avec elle ?

Ce délai se produit en général car le thread principal du navigateur est occupé, et ne peut pas répondre de façon instantanée à l’utilisateur. Le thread principal correspond au flux d’instructions et processus qui permettent d’afficher correctement une page dans le navigateur. Dans ce processus, nous retrouvons l’évaluation du JavaScript ainsi que son interprétation, la lecture du code HTML et sa mise en forme dans le navigateur (compilation du code, rendu,…)

Par exemple, le navigateur via le thread principal peut être en train d’analyser et d’exécuter un gros fichier Javascript, moment pendant lequel il ne peut pas exécuter les écouteurs d’évènements, car le Javascript en cours de chargement pourrait renvoyer d’autres indications.

Si l’on regarde le chargement d’une page Web dans le schéma ci-dessous, nous constatons certaines demandes de ressources (fichiers JS ou CSS) qui ne sont traités par le thread principal seulement une fois qu’elles sont chargées. Le thread principal se trouve donc momentanément occupé sur les différents blocs de couleur beige :

[Cet article est disponible sous sa forme complète pour les abonnés du site Réacteur. Pour en savoir plus : https://www.reacteur.com/2021/05/core-web-vitals-focus-sur-le-fid.html]

Core Web Vitals : focus sur le FID

Un article écrit par Aymeric Bouillat, Consultant SEO senior chez Novalem.