Le truc que je vois le plus souvent quand on m'appelle pour un audit : un site qui claque des scores Lighthouse de 95 partout, et qui reste pourtant désagréable au clic. Vous cliquez sur un menu, il se passe rien pendant une demi-seconde. Puis tout s'exécute d'un coup. C'est exactement le problème que le First Input Delay mesurait, et c'est celui qu'on règle encore aujourd'hui sous un autre nom.
Points clés à retenir
- Le FID a été retiré des Core Web Vitals le 12 mars 2024 et remplacé par l'INP (Interaction to Next Paint).
- Seuils FID : bon sous 100 ms, à améliorer entre 100 et 300 ms, mauvais au-delà de 300 ms.
- Cible INP actuelle : rester sous 200 ms, mesuré au 75e percentile.
- La cause n'est presque jamais le réseau. C'est le thread principal saturé par le JavaScript.
- Une long task dépasse 50 ms. Trois long tasks à la suite sur une interaction, et l'INP explose.
- Découper le JS vaut mieux que le minifier. Toujours.
Améliorer le First Input Delay : d'abord comprendre ce qu'on mesurait vraiment
Le FID ne mesurait pas la vitesse d'affichage. Il mesurait l'attente. Concrètement : le délai entre le moment où vous posez le doigt sur l'écran (ou pressez la souris) et le moment où le navigateur commence à traiter cet événement. Pas la fin du traitement. Le début.
D'où une conséquence contre-intuitive : un site pouvait avoir un FID excellent et une expérience détestable. Réponse instantanée au clic, puis 800 ms de freeze pendant que le script mouline. Le FID souriait. L'utilisateur, beaucoup moins.
C'est précisément pour cette raison que Google a changé de métrique. Le FID ne capturait que le premier délai d'entrée, et il ignorait tout ce qui se passait après. Un site avec un formulaire lourd, une modale qui met une éternité à s'ouvrir, un filtre qui recalcule tout le catalogue — rien de tout ça n'apparaissait.
Pourquoi le délai existe : input delay, processing delay, presentation delay
Quand vous cliquez, votre clic entre dans une file d'attente. Le thread principal — celui qui exécute le JavaScript — fait peut-être autre chose à ce moment-là. Il parse un gros fichier, il exécute une boucle de tri, il hydrate un composant React. Votre clic patiente.
Ce temps d'attente, c'est l'input delay. Vient ensuite le processing delay : le navigateur exécute enfin votre gestionnaire d'événement. Puis le presentation delay : il recalcule le layout et repeint l'écran. Le FID ne regardait que le premier. L'INP additionne les trois, et prend la pire interaction observée (approximativement le 98e percentile des interactions, pour être précis).
Comprendre cette décomposition change tout au diagnostic. Optimiser le FID quand le problème réel est un processing delay de 400 ms revient à repeindre une façade pendant que le toit fuit.
Les vraies causes d'un délai d'interaction trop long
Sur une bonne trentaine de sites que j'ai audités, je n'ai trouvé qu'une seule fois un problème réseau significatif. Une seule. Le reste du temps, c'est le même coupable : du JavaScript qui monopolise le thread.
Les long tasks, ce concept qui explique 80 % des cas
Une long task, c'est une tâche qui occupe le thread principal pendant plus de 50 ms. Pendant qu'elle tourne, le navigateur ne peut rien faire d'autre : ni répondre à un clic, ni mettre à jour l'affichage. Il est bloqué.
Le problème n'est pas la durée totale du JS de votre page. C'est la taille du plus gros bloc indivisible. Un site avec 800 Ko de JS bien découpé en morceaux de 30 ms sera plus réactif qu'un site avec 200 Ko dans un seul script de 400 ms. J'ai vu exactement ce cas : un bundle allégé de 60 % qui n'améliorait rien, parce qu'on avait juste supprimé des dépendances sans toucher au découpage.
Le Total Blocking Time (TBT) mesure ça dans Lighthouse : la somme des portions de long tasks au-delà de 50 ms. C'est un bien meilleur indicateur de réactivité que le FID ne l'a jamais été. Si vous devez retenir un chiffre de cet article pour votre prochain audit, c'est celui-là.
Les coupables que je retrouve systématiquement
- Un script tiers de chat ou de tracking chargé en haut du
<head>, non async - Des gestionnaires d'événements attachés à chaque élément d'une liste de 500 entrées
- Un framework qui hydrate toute la page alors que 10 % seulement sont interactifs
- Des requêtes synchrones dans le code legacy (oui, ça existe encore)
- Et le champion toutes catégories : la régénération complète d'un tableau de données à chaque frappe clavier
Ce dernier cas, je l'ai rencontré sur un back-office de gestion locative. Chaque lettre tapée dans un champ de recherche déclenchait un re-render de 1 200 lignes. L'INP mesuré : 1 400 ms. Les utilisateurs pensaient que le logiciel plantait.
Comment corriger concrètement, dans l'ordre
Étape 1 : réduire et différer le JavaScript
Avant d'optimiser quoi que ce soit, identifiez ce qui bloque. Dans Chrome DevTools, un enregistrement de performance sur un clic vous montre les long tasks en rouge. Impossible de les rater.
Ensuite, dans cet ordre :
- Supprimez les dépendances que personne n'utilise plus (le bundle analyzer fait ce travail en cinq minutes)
- Passez en dynamic import tout ce qui n'est pas visible au premier écran
- Découpez les gros traitements avec
setTimeoutou, mieux,requestIdleCallback - Chargez les scripts tiers en
deferouasync, et surveillez leur coût côté navigateur
Sur un projet e-commerce, cette seule séquence a fait passer l'INP de 480 ms à 160 ms en trois jours. Sans toucher au design, sans changer d'hébergeur. Juste déplacer du code.
Étape 2 : alléger le travail par interaction
Le debounce sur les champs de recherche, c'est la base — mais mal fait, il ne sert à rien. J'ai longtemps mis un délai de 300 ms partout avant de comprendre que le vrai gain venait du yield en cours de traitement : rendre la main au navigateur entre deux lots de lignes à traiter, pour qu'un clic puisse s'intercaler.
Autre point que j'ai mis du temps à accepter : le useMemo mal placé coûte plus cher que le calcul qu'il évite. Sur les petits tableaux, un recalcul direct est souvent plus rapide que sa mise en cache. À vérifier au profileur, jamais à l'instinct.
Étape 3 : le CSS et le rendu, souvent oubliés
Tout le monde se jette sur le JavaScript et zappe deux causes classiques. Les sélecteurs CSS trop profonds, qui ralentissent le recalcul de style à chaque interaction. Et les animations sur des propriétés comme width ou top, qui déclenchent un recalcul de layout à chaque frame au lieu d'une simple composition GPU.
| Levier | Effort | Gain typique observé | Risque de régression |
|---|---|---|---|
| Découpage du bundle JS | Moyen | Élevé (souvent 200 ms et plus) | Faible |
| Scripts tiers en defer | Faible | Variable, dépend du tiers | Nul |
| Debounce / yield sur les traitements | Faible | Moyen à élevé | Faible |
| Animations en transform / opacity | Faible | Moyen | Faible |
| Passage en SSR ou îlots d'interactivité | Élevé | Élevé | Moyen |
Mesurer sans se raconter d'histoires
Le labo et le terrain donnent deux réponses différentes. Lighthouse mesure sur votre machine, avec une connexion simulée, sans utilisateur réel qui scrolle en même temps qu'il clique. Le field data mesure le pire.
Ma règle : je regarde d'abord le 75e percentile des données terrain. Pas la moyenne — elle écrase les mauvaises expériences sous une majorité d'utilisateurs satisfaits. Le 75e percentile, c'est le seuil que Google utilise pour classer une URL comme bonne ou mauvaise, et c'est aussi celui qui correspond aux utilisateurs qui souffrent le plus sans être des cas extrêmes.
Le FID est-il encore une métrique Core Web Vitals ?
Non, plus depuis le 12 mars 2024. Le FID a été remplacé par l'INP (Interaction to Next Paint), qui mesure le délai complet entre une interaction et la mise à jour visuelle suivante, sur l'ensemble des interactions de la visite — pas seulement la première. Si vous optimisez encore pour le FID seul, vous passez à côté de tout ce qui se passe après le premier clic.
Quelle est la différence entre le First Input Delay et l'INP ?
Le FID ne mesurait que le premier délai d'entrée, et uniquement sur la première interaction. L'INP, lui, prend en compte toutes les interactions de la page et mesure le délai complet jusqu'à la prochaine frame rendue. Autrement dit : le FID validait un site qui répond vite puis freeze. L'INP ne pardonne plus cette approximation.
Quels sont les seuils à viser aujourd'hui ?
Pour référence, les seuils FID historiques restent utiles à connaître : bon sous 100 ms, à améliorer entre 100 et 300 ms, mauvais au-delà. Mais ce sont les seuils INP qui comptent en 2026 : sous 200 ms pour un bon score, entre 200 et 500 ms pour un score « à améliorer », au-delà pour un score mauvais. Le tout évalué au 75e percentile sur des données terrain.
Ce qu'il faut retenir, et ce que j'ai arrêté de faire
Pendant deux ans, j'ai optimisé des FID sur des projets qui avaient un INP catastrophique. Je livrais des rapports avec des scores verts, et les utilisateurs continuaient à se plaindre d'un site lent. Le décalage était violent.
Aujourd'hui, je ne mesure plus le FID. Je mesure le TBT en labo et l'INP en terrain, et je cherche les long tasks avant de toucher à quoi que ce soit d'autre. Le découpage du JavaScript reste le levier numéro un — c'est une corvée, ça ne se voit pas dans un rapport client, et c'est ce qui marche.
La question à se poser n'est plus « combien de temps avant que mon site réagisse ? » mais « combien de temps avant qu'il ait fini de réagir ? ». La première n'intéresse que les tableaux de bord. La seconde, ce sont vos visiteurs qui la posent — à leur manière, en quittant l'onglet.
