First Input Delay (FID) : définition et remplacement par l'INP

Qu'est-ce que le First Input Delay (FID) ?

Le First Input Delay (FID) était un Core Web Vital qui mesurait le temps entre la première interaction d'un visiteur avec une page, comme un clic, un toucher ou une frappe, et le moment où le navigateur pouvait commencer à exécuter les gestionnaires d'événements correspondants. Il traduisait l'impression de page « figée » quand JavaScript occupe le fil principal pendant le chargement et que la page ne peut pas réagir. Un bon FID était de 100 millisecondes ou moins au 75e centile.

Le FID n'est plus un Core Web Vital. L'Interaction to Next Paint (INP) l'a remplacé le 12 mars 2024 et, selon web.dev, la prise en charge du FID a pris fin le 9 septembre 2024. Cette page explique ce qu'était le FID et en quoi il diffère de l'INP. Pour tout ce que vous mesurez ou corrigez aujourd'hui, utilisez l'INP.

Comment fonctionnait le FID

Le FID ne mesurait que le délai d'entrée de la première interaction sur une page : l'écart entre l'action et le moment où ses gestionnaires pouvaient démarrer. Il n'incluait ni la durée d'exécution des gestionnaires ni le temps d'affichage du résultat. Les actions continues, comme le défilement et le zoom, en étaient exclues.

Il ne pouvait se mesurer qu'avec de vrais utilisateurs, car il faut une vraie première interaction. En laboratoire, le Total Blocking Time (TBT) servait de substitut, et web.dev note qu'il était bien corrélé au FID sur le terrain.

FID et INP : les différences

Pourquoi le FID a été remplacé

• Il ne voyait qu'une interaction. Une page pouvait avoir un bon FID et paraître lente au dixième clic.
• Il ignorait la réponse. Les gestionnaires lents et l'affichage lent après l'action ne comptaient pas.
• Il était facile à valider. Les visiteurs qui interagissaient une fois la page stabilisée ne ressentaient presque aucun délai : beaucoup de sites passaient sans être réactifs.

Ce qui reste valable

Les causes d'un mauvais FID sont aussi celles d'un mauvais INP, donc l'essentiel des anciens conseils s'applique toujours : tâches JavaScript longues, gros bundles, scripts tiers, hydratation lourde et gestionnaires d'événements lents. Découpez les tâches longues, chargez le code seulement quand il est nécessaire et différez ce qui n'est pas urgent. Erreurs fréquentes aujourd'hui : suivre encore le FID dans les tableaux de bord et les alertes, et prendre un rapport de FID « validé » d'avant 2024 comme preuve que la page est réactive.

Mesurer la réactivité aujourd'hui

Consultez l'INP dans les données de terrain du Chrome UX Report (CrUX). Le vérificateur gratuit de Core Web Vitals indique LCP, INP et CLS à partir du CrUX et, comme le précise sa page, affiche l'INP, pas le FID. Pour suivre tous les Core Web Vitals dans le temps, le suivi de la vitesse de page de LoadFocus lance des audits Lighthouse planifiés qui incluent le Total Blocking Time. Le guide d'optimisation complet est How to Optimize Interaction to Next Paint, et pour les alertes et rapports, voir How to monitor Core Web Vitals (en anglais). La définition d'origine du FID est archivée sur web.dev.

Questions fréquentes sur le First Input Delay

Le FID est-il toujours un Core Web Vital ?

Non. L'INP a remplacé le FID comme Core Web Vital le 12 mars 2024.

Quel était un bon FID ?

100 millisecondes ou moins au 75e centile des chargements de page.

Quelle différence entre le FID et l'INP ?

Le FID ne mesurait que le délai d'entrée de la première interaction. L'INP mesure chaque interaction, de l'action au prochain affichage, et retient la plus lente.

Vois-je encore le FID dans mes outils ?

Certains anciens rapports et bibliothèques peuvent encore l'afficher, mais Google a basculé ses outils sur l'INP. Selon web.dev, la prise en charge du FID a pris fin le 9 septembre 2024 : ne comptez pas dessus.

Un bon FID garantit-il un bon INP ?

Pas forcément. Une page peut réagir vite à la première action et rester lente lors de clics ultérieurs ou dans ses gestionnaires d'événements, ce que le FID ne mesurait jamais.