First Input Delay (FID)

Philip Walton

Browser Support

• 76
• 79
• 89
• 26.2

Source

Avertissement : Le First Input Delay (FID) n'est plus une métrique Core Web Vitals. Il a été remplacé par la métrique Interaction to Next Paint (INP). Par conséquent, la prise en charge de l'ID de fichier a cessé le 9 septembre 2024. Vous devez maintenant vous concentrer sur l'INP.

Nous savons tous à quel point il est important de faire bonne impression. C'est important lorsque vous rencontrez de nouvelles personnes, mais aussi lorsque vous créez des expériences sur le Web.

Sur le Web, une bonne première impression peut faire la différence entre un utilisateur qui devient fidèle et un utilisateur qui quitte votre site et ne revient jamais. La question est la suivante : qu'est-ce qui fait une bonne impression et comment mesurer le type d'impression que vous faites probablement sur vos utilisateurs ?

Sur le Web, les premières impressions peuvent prendre de nombreuses formes. Nous avons les premières impressions sur la conception et l'attrait visuel d'un site, ainsi que les premières impressions sur sa vitesse et sa réactivité.

Il est difficile de mesurer à quel point les utilisateurs apprécient la conception d'un site avec les API Web, mais il est tout à fait possible de mesurer sa vitesse et sa réactivité.

La première impression des utilisateurs sur la vitesse de chargement de votre site peut être mesurée avec la métrique First Contentful Paint (FCP). Mais la vitesse à laquelle votre site peut peindre des pixels à l'écran n'est qu'une partie de l'histoire. Il est tout aussi important de vérifier la réactivité de votre site lorsque les utilisateurs tentent d'interagir avec ces pixels.

La métrique First Input Delay (FID) permet de mesurer la première impression de vos utilisateurs concernant l'interactivité et la réactivité de votre site.

Qu'est-ce que le FID ?

Le FID mesure le délai entre le moment où un utilisateur interagit pour la première fois avec une page (c'est-à-dire lorsqu'il clique sur un lien, appuie sur un bouton ou utilise une commande JavaScript personnalisée) et le moment où le navigateur est réellement en mesure de commencer à traiter les gestionnaires d'événements en réponse à cette interaction.

Qu'est-ce qu'un bon score FID ?

Pour offrir une expérience utilisateur de qualité, les sites doivent s'efforcer de ne pas dépasser un délai avant la première interaction de 100 millisecondes. Afin de vous assurer d'atteindre cet objectif pour la plupart de vos utilisateurs, un bon seuil à mesurer est le 75e centile de vos chargements de page, segmentés entre appareils mobiles et ordinateurs.

Remarque  : Pour en savoir plus sur la recherche et la méthodologie à l'origine de cette recommandation, consultez Définir les seuils des métriques Core Web Vitals.

FID en détail

En tant que développeurs qui écrivent du code répondant à des événements, nous supposons souvent que notre code va être exécuté immédiatement, dès que l'événement se produit. Mais en tant qu'utilisateurs, nous avons tous fréquemment vécu le contraire : nous avons chargé une page Web sur notre téléphone, essayé d'interagir avec elle, puis avons été frustrés lorsque rien ne s'est passé.

En général, le délai d'entrée (ou latence d'entrée) se produit parce que le thread principal du navigateur est occupé à faire autre chose et ne peut donc pas (encore) répondre à l'utilisateur. Cela peut se produire, par exemple, lorsque le navigateur est occupé à analyser et à exécuter un fichier JavaScript volumineux chargé par votre application. Pendant ce temps, il ne peut exécuter aucun écouteur d'événements, car le code JavaScript qu'il charge peut lui demander de faire autre chose.

Le FID ne mesure que le "délai" de traitement des événements. Il ne mesure pas la durée totale du traitement des événements lui-même, ni le temps nécessaire au navigateur pour mettre à jour l'UI après l'exécution des gestionnaires d'événements. Bien que ce temps affecte l'expérience utilisateur, l'inclure dans le FID inciterait les développeurs à répondre aux événements de manière asynchrone, ce qui améliorerait la métrique, mais probablement l'expérience. Pour en savoir plus, consultez Pourquoi ne prendre en compte que le délai d'entrée ? ci-dessous.

Voici le déroulement typique du chargement d'une page Web :

La visualisation ci-dessus montre une page qui effectue quelques requêtes réseau pour des ressources (très probablement des fichiers CSS et JS). Une fois ces ressources téléchargées, elles sont traitées sur le thread principal.

Cela entraîne des périodes où le thread principal est momentanément occupé, ce qui est indiqué par les blocs task de couleur beige.

Les longs délais de première entrée se produisent généralement entre le First Contentful Paint (FCP) et le Time to Interactive (TTI), car la page a affiché une partie de son contenu, mais n'est pas encore interactive de manière fiable. Pour illustrer ce cas de figure, le FCP et le TTI ont été ajoutés à la timeline :

Vous avez peut-être remarqué qu'il y a un certain temps (y compris trois tâches longues) entre le FCP et le TTI. Si un utilisateur tente d'interagir avec la page pendant cette période (par exemple, en cliquant sur un lien), il y aura un délai entre le moment où le clic est reçu et le moment où le thread principal est en mesure de répondre.

Imaginez ce qui se passerait si un utilisateur essayait d'interagir avec la page au début de la tâche la plus longue :

Étant donné que l'entrée se produit alors que le navigateur est en train d'exécuter une tâche, il doit attendre que la tâche se termine avant de pouvoir répondre à l'entrée. Le temps d'attente doit correspondre à la valeur FID de cet utilisateur sur cette page.

Remarque  : Dans cet exemple, l'utilisateur a interagi avec la page au début de la période la plus chargée du thread principal. Si l'utilisateur avait interagi avec la page un instant plus tôt (pendant la période d'inactivité), le navigateur aurait pu répondre immédiatement. Cette variance du délai d'entrée souligne l'importance d'examiner la distribution des valeurs FID lors de la création de rapports sur la métrique. Pour en savoir plus, consultez la section ci-dessous sur l'analyse et la création de rapports sur les données FID.

Que se passe-t-il si une interaction n'a pas d'écouteur d'événements ?

Le FID mesure le delta entre le moment où un événement d'entrée est reçu et le moment où le thread principal est inactif. Cela signifie que le FID est mesuré même lorsqu'un écouteur d'événement n'a pas été enregistré. En effet, de nombreuses interactions utilisateur ne nécessitent pas d'écouteur d'événement, mais nécessitent que le thread principal soit inactif pour s'exécuter.

Par exemple, tous les éléments HTML suivants doivent attendre que les tâches en cours sur le thread principal soient terminées avant de répondre aux interactions des utilisateurs :

• Champs de texte, cases à cocher et cases d'option (<input>, <textarea>)
• Sélectionner des menus déroulants (<select>)
• liens (<a>)

Pourquoi ne prendre en compte que la première entrée ?

Bien qu'un retard de réponse à une entrée puisse nuire à l'expérience utilisateur, nous vous recommandons principalement de mesurer le délai avant la première interaction pour plusieurs raisons :

• Le premier délai d'entrée correspond à la première impression de l'utilisateur concernant la réactivité de votre site. Or, les premières impressions sont essentielles pour façonner notre impression globale de la qualité et de la fiabilité d'un site.
• Les problèmes d'interactivité les plus importants que nous observons aujourd'hui sur le Web se produisent lors du chargement des pages. Nous pensons donc qu'en nous concentrant d'abord sur l'amélioration de la première interaction des utilisateurs avec les sites, nous aurons le plus d'impact sur l'amélioration de l'interactivité globale du Web.
• Les solutions recommandées pour corriger les délais de la première interaction élevés (fractionnement du code, chargement de moins de JavaScript au départ, etc.) ne sont pas nécessairement les mêmes que celles pour corriger les délais d'interaction lents après le chargement de page. En séparant ces métriques, nous pourrons fournir des consignes de performances plus spécifiques aux développeurs Web.

Qu'est-ce qu'une première entrée ?

Le FID est une métrique qui mesure la réactivité d'une page lors de son chargement. Par conséquent, il se concentre uniquement sur les événements d'entrée provenant d'actions discrètes telles que les clics, les appuis et les pressions de touches.

D'autres interactions, comme le défilement et le zoom, sont des actions continues et ont des contraintes de performances complètement différentes (de plus, les navigateurs sont souvent capables de masquer leur latence en les exécutant sur un thread distinct).

En d'autres termes, la FID se concentre sur la réactivité (R) dans le modèle de performances RAIL, tandis que le défilement et le zoom sont davantage liés à l'animation (A). Leurs qualités de performances doivent être évaluées séparément.

Que se passe-t-il si un utilisateur n'interagit jamais avec votre site ?

Tous les utilisateurs n'interagissent pas avec votre site à chaque fois qu'ils le consultent. De plus, toutes les interactions ne sont pas pertinentes pour le FID (comme indiqué dans la section précédente). De plus, certaines premières interactions des utilisateurs se produiront à des moments inopportuns (lorsque le thread principal est occupé pendant une longue période), tandis que d'autres se produiront à des moments opportuns (lorsque le thread principal est complètement inactif).

Cela signifie que certains utilisateurs n'auront aucune valeur FID, d'autres auront des valeurs FID faibles et d'autres encore auront probablement des valeurs FID élevées.

La façon dont vous suivez, signalez et analysez le FID sera probablement très différente des autres métriques auxquelles vous êtes peut-être habitué. La section suivante explique comment procéder.

Pourquoi ne tenir compte que du délai d'entrée ?

Comme indiqué ci-dessus, le FID ne mesure que le "délai" de traitement des événements. Il ne mesure pas la durée totale du traitement des événements lui-même, ni le temps nécessaire au navigateur pour mettre à jour l'UI après l'exécution des gestionnaires d'événements.

Même si ce temps est important pour l'utilisateur et affecte l'expérience, il n'est pas inclus dans cette métrique, car cela pourrait inciter les développeurs à ajouter des solutions de contournement qui détériorent en réalité l'expérience. En d'autres termes, ils pourraient encapsuler la logique de leur gestionnaire d'événements dans un rappel asynchrone (via setTimeout() ou requestAnimationFrame()) afin de la séparer de la tâche associée à l'événement. Le score de la métrique serait amélioré, mais la réponse perçue par l'utilisateur serait plus lente.

Toutefois, alors que le FID ne mesure que la partie "délai" de la latence des événements, les développeurs qui souhaitent suivre une plus grande partie du cycle de vie des événements peuvent le faire à l'aide de l'API Event Timing. Pour en savoir plus, consultez le guide sur les métriques personnalisées.

Mesurer le FID

Le FID est une métrique qui ne peut être mesurée que sur le terrain, car elle nécessite qu'un utilisateur réel interagisse avec votre page. Vous pouvez mesurer le FID avec les outils suivants.

Remarque  : Le FID nécessite un utilisateur réel et ne peut donc pas être mesuré en laboratoire. Toutefois, la métrique Total Blocking Time (TBT) peut être mesurée en laboratoire. Elle est bien corrélée au FID sur le terrain et permet également de détecter les problèmes qui affectent l'interactivité. Les optimisations qui améliorent le TBT en laboratoire devraient également améliorer le FID pour vos utilisateurs.

Outils de champ

• Rapport sur l'expérience utilisateur de Chrome
• PageSpeed Insights
• Search Console (rapport "Signaux Web essentiels")
• Bibliothèque JavaScript web-vitals

Mesurer le FID en JavaScript

Pour mesurer le FID en JavaScript, vous pouvez utiliser l'API Event Timing. L'exemple suivant montre comment créer un PerformanceObserver qui écoute les entrées first-input et les consigne dans la console :

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    const delay = entry.processingStart - entry.startTime;
    console.log('FID candidate:', delay, entry);
  }
}).observe({type: 'first-input', buffered: true});

Avertissement  : Ce code montre comment consigner les entrées first-input dans la console et calculer leur délai. Toutefois, la mesure du FID en JavaScript est plus complexe. Pour en savoir plus, consultez les informations ci-dessous :

Dans l'exemple ci-dessus, la valeur du délai de l'entrée first-input est mesurée en prenant le delta entre les codes temporels startTime et processingStart de l'entrée. Dans la plupart des cas, il s'agit de la valeur FID. Toutefois, toutes les entrées first-input ne sont pas valides pour mesurer la FID.

La section suivante liste les différences entre ce que l'API indique et la façon dont la métrique est calculée.

Différences entre la métrique et l'API

• L'API enverra des entrées first-input pour les pages chargées dans un onglet en arrière-plan, mais ces pages doivent être ignorées lors du calcul du FID.
• L'API enverra également des entrées first-input si la page a été mise en arrière-plan avant la première entrée, mais ces pages doivent également être ignorées lors du calcul du FID (les entrées ne sont prises en compte que si la page était au premier plan pendant toute la durée).
• L'API ne signale pas les entrées first-input lorsque la page est restaurée à partir du cache back/forward, mais le FID doit être mesuré dans ces cas, car les utilisateurs les considèrent comme des visites de pages distinctes.
• L'API ne signale pas les entrées qui se produisent dans les iFrames, mais la métrique le fait, car elles font partie de l'expérience utilisateur de la page. Cela peut se traduire par une différence entre CrUX et RUM. Pour mesurer correctement le FID, vous devez les prendre en compte. Les sous-frames peuvent utiliser l'API pour signaler leurs entrées first-input au frame parent à des fins d'agrégation.

Remarque  : Dans certains cas (comme les iFrames d'origine croisée), il n'est pas possible de mesurer le FID en JavaScript.

Analyser les données FID et créer des rapports

En raison de la variance attendue des valeurs FID, il est essentiel que, lorsque vous générez des rapports sur la FID, vous examiniez la distribution des valeurs et que vous vous concentriez sur les centiles les plus élevés.

Bien que le choix du centile pour tous les seuils Core Web Vitals soit le 75e, nous vous recommandons vivement de consulter les 95e à 99e centiles pour le FID en particulier, car ils correspondent aux premières expériences particulièrement mauvaises que les utilisateurs ont avec votre site. Il vous indiquera également les domaines qui nécessitent le plus d'améliorations.

Cela est valable même si vous segmentez vos rapports par catégorie ou type d'appareil. Par exemple, si vous générez des rapports distincts pour les ordinateurs et les mobiles, la valeur FID qui vous intéresse le plus sur ordinateur doit correspondre au 95e à 99e centile des utilisateurs d'ordinateurs, et la valeur FID qui vous intéresse le plus sur mobile doit correspondre au 95e à 99e centile des utilisateurs de mobiles.

Améliorer le FID

Un guide complet sur l'optimisation du FID est disponible pour vous présenter les techniques permettant d'améliorer cette métrique.

Journal des modifications

Il arrive que des bugs soient découverts dans les API utilisées pour mesurer les métriques, et parfois dans les définitions des métriques elles-mêmes. Par conséquent, des modifications doivent parfois être apportées. Elles peuvent apparaître comme des améliorations ou des régressions dans vos rapports et tableaux de bord internes.

Pour vous aider à gérer cela, toutes les modifications apportées à l'implémentation ou à la définition de ces métriques seront indiquées dans ce journal des modifications.

Si vous avez des commentaires à faire sur ces métriques, vous pouvez les envoyer dans le groupe Google web-vitals-feedback.