First Input Delay FID

Vitesse et performance : First Input Delay (FID), Délai de première entrée et rôle historique dans les Core Web Vitals

Introduction

La vitesse et la performance d'un site web sont des facteurs critiques pour l'expérience utilisateur et le référencement naturel. Pendant plusieurs années, le First Input Delay (FID), ou délai de première entrée, a été l’une des métriques Core Web Vitals historiques utilisées par Google pour évaluer la réactivité des pages. Même si FID a été remplacé comme métrique principale de réactivité par Interaction to Next Paint (INP) depuis 2024, il reste essentiel de comprendre ce qu’il mesure, comment il fonctionne et comment les optimisations orientées FID restent pertinentes pour améliorer la performance globale d’un site.

Le FID mesure le temps que met un navigateur à commencer à répondre à la première interaction d’un utilisateur, comme un clic sur un bouton ou une pression de touche sur un clavier. Une bonne performance en termes de FID est un indicateur fort de réactivité perçue, en particulier lors de la phase de chargement initial de la page.

Cet article explique en détail la notion de First Input Delay, son rôle historique dans les Core Web Vitals, sa relation avec INP et d’autres métriques de performance, ainsi que les bonnes pratiques techniques pour améliorer la réactivité des pages web.

Contexte : FID, INP et Core Web Vitals en 2025

Pour bien situer le FID dans le paysage de la performance web en 2025, il est important de distinguer :

• Les Core Web Vitals historiques : FID faisait partie du trio d’origine avec LCP (Largest Contentful Paint) et CLS (Cumulative Layout Shift). Il a longtemps été utilisé comme signal de classement dans l’algorithme de Google pour mesurer la réactivité.
• Les Core Web Vitals actuels : depuis mars 2024, FID a été remplacé par INP (Interaction to Next Paint) comme métrique officielle de réactivité. Les Core Web Vitals majeurs sont désormais LCP, INP et CLS.

En d’autres termes, FID est aujourd’hui une métrique historique : elle reste utile pour comprendre la réactivité initiale d’une page et pour analyser l’évolution des performances, mais ce n’est plus la métrique utilisée par Google comme signal Core Web Vital de réactivité. C’est désormais INP qui joue ce rôle et qui tient compte de toutes les interactions, pas uniquement de la première.

Concepts clés

Avant d’aller plus loin, il est essentiel de maîtriser certains concepts fondamentaux liés à FID et à la performance de la réactivité.

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

Le First Input Delay désigne le délai, exprimé en millisecondes, entre le moment où un utilisateur interagit pour la première fois avec une page (clic, tap sur écran tactile, pression de touche, etc.) et le moment où le navigateur peut commencer à traiter cette interaction.

Concrètement, FID mesure la latence d’entrée initiale : si le thread principal du navigateur est occupé par des tâches longues (par exemple du JavaScript en cours d’exécution), il ne peut pas tout de suite traiter l’événement d’entrée. Le FID correspond donc au temps d’attente avant le début du traitement de cet événement. Il ne mesure pas :

• la durée totale d’exécution du gestionnaire d’événement,
• ni le délai nécessaire pour afficher le prochain frame (rafraîchissement visuel) après le traitement.

En résumé, FID se concentre sur le moment où l’utilisateur tente d’interagir et demande au navigateur de faire quelque chose, et sur le temps que met le navigateur à devenir disponible pour commencer à répondre.

Définition chiffrée et formule du FID

Techniquement, le FID est défini comme :

FID = processingStart - startTime

où :

• startTime correspond au moment exact où l’interaction utilisateur est enregistrée (clic, tap, keydown, etc.),
• processingStart correspond au moment où le navigateur commence réellement à traiter l’événement associé.

Cette définition met bien en évidence que le FID n’inclut pas le temps d’exécution du code du gestionnaire d’événement lui-même, ni le délai d’affichage visuel qui suit. Il se limite au délai entre l’entrée utilisateur et le début de la réponse du navigateur.

FID versus autres métriques de performance

Le FID doit être considéré en contexte avec d’autres indicateurs de performance web :

• LCP (Largest Contentful Paint) : mesure le temps nécessaire pour que l’élément de contenu principal (texte, image, vidéo) soit rendu à l’écran. C’est une métrique centrée sur la vitesse de chargement perçue.
• FCP (First Contentful Paint) : mesure le moment où le premier élément de contenu (texte, image, SVG, etc.) apparaît à l’écran. Elle renseigne sur la rapidité avec laquelle l’utilisateur voit apparaître quelque chose.
• CLS (Cumulative Layout Shift) : mesure la stabilité visuelle de la page en quantifiant les déplacements inattendus des éléments lors du chargement. Elle concerne la confortabilité visuelle.
• TBT (Total Blocking Time) : mesure, en laboratoire, la somme des temps pendant lesquels le thread principal est bloqué par des tâches de plus de 50 ms entre le FCP et le Time to Interactive. TBT est étroitement corrélé à la réactivité et sert de proxy en labo pour des métriques comme FID.
• INP (Interaction to Next Paint) : remplaçant moderne de FID, INP mesure la réactivité globale d’une page sur toutes les interactions (et pas seulement la première), en intégrant l’entrée, le traitement et l’affichage.

Alors que des métriques comme FCP et LCP se concentrent sur l’affichage du contenu, FID s’intéresse à la réactivité après l’apparition du contenu. Aujourd’hui, cette vision de la réactivité est prolongée et enrichie par INP, qui couvre l’ensemble de la session utilisateur.

Comment est mesuré le FID ?

La mesure de FID suit une séquence claire d’événements :

1. L’utilisateur effectue une première interaction avec la page (clic sur un lien, appui sur un bouton, pression d’une touche, tap sur un élément interactif, etc.).
2. Le navigateur enregistre le moment exact de cette interaction (startTime).
3. Le navigateur attend que le thread principal soit disponible pour commencer à gérer cette interaction.
4. Quand le traitement de l’événement peut enfin débuter, le navigateur enregistre ce moment (processingStart).
5. La différence entre processingStart et startTime est calculée : c’est le First Input Delay.

Un point essentiel : le FID ne mesure pas la durée de la tâche de traitement de l’événement. Il se limite au temps pendant lequel l’utilisateur attend que le navigateur puisse commencer à répondre. Ce détail est fondamental pour interpréter correctement la métrique.

FID : métrique uniquement terrain (field data)

Un aspect souvent mal compris est la nature même de FID : il s’agit d’une métrique terrain, calculée à partir des données d’utilisateurs réels. Cela signifie que :

• FID n’est pas directement mesuré dans des environnements de test synthétiques comme un audit isolé sur une machine de développement.
• Les outils de lab tels que Lighthouse ou la plupart des tests de performance synthétiques ne peuvent pas produire un FID réel, car il n’y a pas de véritable interaction utilisateur dans ces scénarios.
• Pour analyser le FID, on s’appuie sur des données de terrain issues de sources comme le Chrome UX Report (CrUX) ou des solutions de Real User Monitoring (RUM) intégrées côté client.

En laboratoire, la métrique utilisée comme approximation de la réactivité est le Total Blocking Time (TBT), qui est fortement corrélé avec FID. Un TBT faible suggère généralement un FID très bas, notamment sur des appareils de performance comparable.

Outils pour consulter ou analyser FID

Même si FID n’est plus la métrique de référence pour la réactivité, il reste consultable dans plusieurs outils, notamment pour les périodes historiques ou pour analyser les anciennes performances :

• Chrome User Experience Report (CrUX) : base de données publique de performances réelles collectées depuis Chrome.
• Google Search Console : anciennement via les rapports Core Web Vitals, où FID a été peu à peu remplacé par INP.
• Bibliothèque JavaScript Web Vitals : permet de collecter le FID directement depuis les navigateurs des utilisateurs et de l’envoyer vers des outils d’analyse.
• Solutions RUM (Real User Monitoring) tierces : intègrent souvent FID parmi d’autres métriques de réactivité et de performance.

En revanche, des outils comme Google Lighthouse, GTmetrix ou des tests de performance synthétiques rapportent principalement TBT, pas FID lui-même.

Seuils de qualité pour le FID

Historiquement, les seuils utilisés pour évaluer la qualité d’un FID étaient les suivants :

• Bon : FID inférieur à 100 ms.
• À améliorer : FID compris entre 100 ms et 300 ms.
• Mauvais : FID supérieur à 300 ms.

Pour qu’un site soit considéré comme performant sur le plan de la réactivité initiale, au moins 75 % des chargements de page (tous appareils confondus, mobile et desktop) devaient afficher un FID inférieur à 100 ms. Cette approche par percentile (75ᵉ percentile) reste une référence pour évaluer la qualité d’expérience utilisateur.

Rôle historique de FID dans le SEO et la performance

Lorsque Google a introduit les Core Web Vitals, FID a été inclus comme l’une des trois métriques principales aux côtés de LCP et CLS. À ce titre, il a été utilisé comme un signal de classement pour Google Search, influençant la visibilité des pages dans les résultats de recherche.

Cependant, FID présentait des limitations :

• Il ne mesurait que la première interaction, laissant de côté les interactions ultérieures potentiellement lentes.
• Il ne prenait pas en compte la durée d’exécution des gestionnaires d’événements ni le délai lié à l’affichage du prochain frame.

Pour répondre à ces limites, Google a introduit Interaction to Next Paint (INP), d’abord comme métrique expérimentale, puis comme remplaçant officiel de FID dans les Core Web Vitals à partir de 2024. Depuis ce changement, il n’est plus exact de considérer FID comme une métrique Core Web Vital actuelle ou comme un signal de classement en 2025. C’est désormais INP qui remplit ce rôle pour la réactivité.

Facteurs qui dégradent le FID

Un mauvais FID est généralement le symptôme d’un thread principal surchargé au moment de la première interaction. Plusieurs facteurs peuvent contribuer à cette surcharge :

• JavaScript lourd et non optimisé : bundles volumineux, frameworks chargés dans leur intégralité alors qu’une partie seulement est nécessaire, logique applicative complexe exécutée dès le chargement.
• Longues tâches (long tasks) : exécution de blocs de code dépassant 50 ms sur le thread principal, empêchant toute réponse rapide aux entrées utilisateur.
• Scripts tiers : solutions publicitaires, analytics, widgets sociaux, chat en ligne, A/B testing et autres scripts externes peuvent bloquer le thread principal et allonger le délai avant le traitement des interactions.
• CSS bloquant le rendu : feuilles de style critiques non optimisées ou chargées de manière bloquante, retardant l’interactivité.
• DOM très volumineux : trop grand nombre de nœuds dans le DOM, entraînant des coûts de parsing, de mise en page et de rendu importants.
• Travaux coûteux côté rendu : recalculs de layout fréquents, style recalculé sur de grandes parties de la page, opérations de peinture complexes.
• Mauvaise répartition du travail entre le client et le serveur : trop de logique exécutée côté client au lieu d’être traitée en amont (par exemple, absence de rendu côté serveur ou d’hydratation progressive).

La combinaison de ces facteurs peut faire que, lorsqu’un utilisateur clique ou tape pour la première fois, le navigateur est encore occupé à exécuter du code ou à effectuer des opérations de rendu, ce qui augmente le FID.

Bonnes pratiques pour améliorer le FID (et la réactivité globale)

Les stratégies qui permettaient d’améliorer FID restent pleinement pertinentes pour améliorer la réactivité mesurée aujourd’hui par INP et, plus largement, pour optimiser l’expérience utilisateur. Voici les principales approches :

1. Optimiser les ressources JavaScript

Le JavaScript est souvent la source principale de blocage du thread principal. Pour réduire ce blocage et améliorer la réactivité :

• Réduisez la taille des bundles : mettez en place du bundling intelligent, du code splitting et de la minification afin de limiter la quantité de JavaScript chargée au démarrage.
• Chargez les scripts de manière non bloquante : utilisez les attributs async et defer pour les scripts externes, afin d’éviter de bloquer le parsing HTML et de retarder l’interactivité.
• Évitez les scripts inutiles : supprimez les bibliothèques ou plugins non utilisés, les polyfills devenus superflus et les codes expérimentaux laissés en production.
• Privilégiez des bibliothèques légères : remplacez, quand c’est possible, de gros frameworks par des alternatives plus légères, ou limitez l’usage de fonctionnalités lourdes.
• Reportez le travail non critique : décalez certaines tâches (fetch de données secondaires, enrichissements visuels, analytics non critiques) à après la phase d’interaction initiale.

2. Fractionner les longues tâches (long tasks)

Les longues tâches JavaScript (supérieures à 50 ms) bloquent la boucle d’événements et empêchent toute réponse rapide aux interactions. Pour les traiter :

• Identifiez les long tasks : utilisez les outils de performance des navigateurs pour repérer les tâches qui dépassent 50 ms.
• Divisez les tâches : découpez les traitements lourds en segments plus petits, éventuellement à l’aide de setTimeout, requestIdleCallback ou d’APIs d’ordonnancement.
• Déplacez les traitements lourds : si possible, exécutez le travail intensif dans des Web Workers pour libérer le thread principal.

L’objectif est de rendre le thread principal disponible aussi souvent que possible, de manière à ce que, lorsqu’un utilisateur interagit, l’entrée puisse être traitée presque immédiatement, ce qui améliore à la fois FID et INP.

3. Optimiser le temps de réponse du serveur

Un serveur lent n’impacte pas directement le calcul de FID, mais un chargement initial long retarde la phase où l’utilisateur peut interagir et augmente la probabilité que des tâches lourdes soient encore en cours lors du premier clic. Pour limiter cela :

• Hébergez votre site sur une infrastructure performante et fiable.
• Utilisez un CDN (Content Delivery Network) pour rapprocher les ressources des utilisateurs géographiquement.
• Optimisez vos bases de données (index, requêtes, caches applicatifs) pour réduire les temps de réponse.
• Mettez en place du caching côté serveur (page cache, fragments cache) pour servir plus vite les pages très consultées.

4. Mettre en œuvre le chargement différé (lazy loading)

Le chargement différé permet de n’importer que les ressources nécessaires au moment où l’utilisateur en a besoin, ce qui allège fortement le travail initial du navigateur :

• Utilisez l’attribut loading="lazy" pour les balises et