Une page mobile qui s’affiche en un clin d’œil peut quand même donner cette impression bizarre de ne pas répondre au premier tapotement. On clique, rien ne bouge pendant un instant, puis l’action part. Le First Input Delay servait justement à mesurer cette attente avant que le navigateur puisse traiter le clic. Il a disparu des Core Web Vitals le 12 mars 2024, remplacé par l’INP, mais ce qu’il mesurait reste un bon point de départ pour comprendre pourquoi votre page reste pâteuse au premier geste.
Ce que le FID mesurait vraiment, et rien de plus
Le FID chronométrait un intervalle précis : entre le moment où un visiteur touche l’écran (clic sur un lien, appui sur un bouton, usage d’une commande JavaScript personnalisée) et le moment où le navigateur pouvait enfin lancer les gestionnaires d’événements. Rien sur le temps de traitement, rien sur l’affichage. Sa portée s’arrêtait là, et cette limite explique en partie pourquoi Google l’a retiré. Pour situer les différentes métriques entre elles, le site mohedaltrad2020.fr détaille les seuils et les cas d’usage de chacune.
Google classait un FID bon à 100 millisecondes et mauvais à 300 millisecondes. Entre les deux, il fallait améliorer. Ces repères restent utiles pour comprendre l’ordre de grandeur d’une attente perceptible : au-delà de cent millisecondes, l’utilisateur commence à sentir que quelque chose coince. Le FID ne mesurait que la toute première interaction de la visite, ce qui en faisait un indicateur partiel, presque un aperçu.
Pourquoi une page rapide peut rester pâteuse au premier clic
Le chargement rapide et la réactivité sont deux chantiers distincts. Une page peut afficher son contenu très vite, obtenir un bon score au First Contentful Paint, et bloquer quand même le premier clic. Le FCP mesure la première impression visuelle de vitesse, il ne dit rien du fil principal occupé à autre chose au moment du geste. Un script tiers, une analyse, un hydrateur JavaScript lourd peut retenir ce fil au mauvais moment.
Le problème se voit surtout sur mobile, où le processeur est plus lent et le réseau moins stable. Le navigateur peut afficher du texte puis continuer à exécuter des tâches en arrière-plan. L’utilisateur, lui, a déjà posé son doigt. Le délai qu’il ressent correspond alors exactement à ce que le FID mesurait : le temps avant que le navigateur daigne s’occuper de son clic. Comprendre ce décalage aide à cibler les scripts qui monopolisent le fil principal.
FID et INP : deux regards différents sur la même gêne
L’INP, la métrique qui a pris le relais le 12 mars 2024, change l’échelle d’analyse. Il mesure toutes les interactions de la visite et l’interaction complète : le délai avant traitement, le temps de traitement lui-même et le temps jusqu’au prochain rendu.
Là où le FID s’arrêtait au premier clic, l’INP juge l’ensemble du parcours et la réactivité visuelle finale. Une page peut avoir un FID correct et un INP médiocre, ce qui révèle des gestionnaires d’événements lents ou un rendu qui traîne. Sur ce point, voir aussi notre article sur indexation demande google.
Cette différence a une conséquence pratique. Diagnostiquer un clic pâteux en 2025 ne consiste plus à traquer uniquement l’attente initiale, mais à décomposer chaque interaction pour trouver l’étape qui casse la fluidité. Le FID sert encore de boussole mentale : il isole le premier contact, souvent le plus scruté par l’utilisateur pressé qui juge la page sur son tout premier geste.
Trois symptômes qui trahissent un fil principal saturé
- Le bouton réagit avec un temps de retard perceptible au premier appui, puis devient fluide.
- Un défilement saccadé juste après le chargement, avant que tout se stabilise.
- L’utilisateur clique deux fois parce qu’il croit que son premier geste n’a pas été pris en compte ?
- La zone tactile semble inerte pendant que d’autres éléments de la page répondent normalement.
Ce dernier point mérite une nuance : un élément isolé qui ne répond pas traduit parfois un bug de JavaScript plutôt qu’une saturation générale. Le test décisif consiste à reproduire l’attente sur un appareil mobile réel, avec une connexion bridée, pas sur un ordinateur de bureau puissant.
Traquer le premier clic dans les outils du quotidien
Dans Lighthouse ou les DevTools, aucune trace du FID n’apparaît plus puisqu’il est déprécié. On observe en revanche le fil principal dans l’onglet Performance : un long bloc jaune juste après le chargement indique une tâche qui retient le processeur. Couper cette tâche, différer un script non critique, charger les modules tiers après la première interaction change concrètement la sensation au clic. C’est là que le diagnostic devient concret, sur l’enregistrement, pas sur la théorie.
Franchement, la plupart des pages pâteuses que j’ai vues souffraient du même mal : un ou deux scripts tiers chargés trop tôt. Les désactiver temporairement et comparer les enregistrements suffit souvent à identifier le coupable. La démarche reste empirique, mais elle parle plus que n’importe quel tableau de scores.
Un ancien indicateur encore utile pour lire l’attente
Le FID n’a plus cours officiellement, et ce n’est pas près de revenir. Mais sa logique, isoler le délai avant traitement du premier geste, garde une valeur pédagogique : elle découpe une gêne floue en un temps mesurable. Une page mobile rapide qui répond mal au premier clic cache presque toujours un fil principal encombré à l’instant précis du contact, et c’est cette fenêtre qu’il faut observer dans un enregistrement de performance.
L’INP impose désormais plus de rigueur, en exigeant l’analyse complète de chaque interaction. Le réflexe du FID aide à poser la première question au bon endroit. Reste à voir si votre propre premier clic mérite encore cette attention, ou si vous jugez déjà la page sur son affichage seul.
