Tout comme l’INP, le First Input Delay (FID) était aussi une metric des Core Web Vitals visant à mesurer la réactivité. Elle capturait le délai nécessaire pour compléter la première interaction entre un utilisateur et la page.

Le FID mesurait le temps écoulé entre le moment où un utilisateur interagissait pour la première fois avec la page et le moment où le navigateur répondait à cette interaction.
La mesure de ce délai est particulièrement utile pour les éditeurs et pour Google, par exemple lorsqu’on a mis en place le « Report du chargement du JavaScript » via un plugin comme WP Rocket ou AccelerateWP.

En effet, pour de meilleures performances, ce « Delay JS » a précisément pour effet de d’abord charger la page HTML/CSS, sans le JavaScript… et seulement ensuite (en asynchrone), lors d’une première interaction avec la page (un Clic, une touche de clavier Tapée, ou autre — les éléments Survolés, et le Défilement de la fenêtre ne sont pas comptabilisés par INP), les scripts JS sont chargés (ou même téléchargés), ce qui prend un certain temps / un délai que le FID se charge de mesurer !
Encore une fois, le FID affiché dans les rapports de la Search Console est une metric de terrain qui n’est pas mesurée via un outil ponctuel comme PageSpeed Insights. Une véritable interaction utilisateur est nécessaire pour mesurer le délai de réponse nécessaire pour cette première interaction avec la page.
Le FID représentait déjà une grande avancée lorsque Google l’a introduit comme l’une des metrics des Core Web Vital en 2020. Il offrait aux développeurs une nouvelle façon de mesurer la réactivité des pages telle que les vrais utilisateurs la ressentent.
C’était vraiment le but des Core Web Vitals.
Contrairement à des mesures similaires qui donnait des approximations sur l’interactivité avec la page (comme le Total Blocking Time / TBT, et le Time To Interactive / TTI), le FID mesurait directement l’expérience utilisateur en se basant sur la réactivité des pages au chargement et suite à une première interaction.
Pour aider à prédire le FID en “laboratoire” (donc via PageSpeed Insights par exemple), Google recommande de vérifier le « Total Blocking Time » (TBT). Il mesure des choses différentes, mais les améliorations du TBT correspondent généralement à des améliorations du FID.
Tout comme pour le INP, la principale cause d’un mauvais FID est l’exécution lourde de JavaScript.
Optimiser la manière dont JavaScript “parse”, compile et exécute les scripts sur vos pages réduira directement le FID…
Et vous l’aurez compris, il s’agit souvent plus du travail du développeur JS que de l’intégrateur Web qui, de son côté n’aura souvent comme solution que de changer de script (ou de plugin) pour éviter de charger du JS qui plomberait trop fortement le FID (et/ou l’INP) !
Le First Input Delay (FID), mesurait donc la réactivité après la première interaction, et à ce stade, vous aurez certainement compris les limites de cette metric, et donc, pourquoi celle-ci a été remplacée par l’INP.
Bien que la première “réaction” soit importante, la première interaction n’est pas nécessairement représentative de toutes les interactions de la page, mesurables tout au long du parcours de l’utilisateur sur cette page. De plus, le FID ne mesurait que le délai d’attente avant que le navigateur puisse commencer à gérer l’interaction, et non le délai de l’interaction entière.
Ces limitations sont les raisons pour lesquelles le FID a maintenant été remplacé par l’INP.
Différence entre le FID et l’INP
L’INP, plutôt que de mesurer uniquement la première interaction, prend en compte toutes les interactions, signalant l’une des plus lentes sur toute la durée de la vie de la page.
Et, plutôt que de mesurer uniquement le délai d’attente du chargement du JS (avant que le navigateur commence son travail), l’INP mesure la durée totale depuis le début de l’interaction, à travers le gestionnaire d’événements, et jusqu’à ce que le navigateur soit capable de “Paint the Next frame” (donc, “passer à la suite”). D’où son nom, “Interaction to Next Paint”.
Cette nouvelle technologie de mesure plus détaillée et complexe font de l’INP une metric beaucoup plus précise que le FID pour s’assurer de l’expérience perçue par l’utilisateur.
Avant 2024, beaucoup de sites web étaient déjà tranquilles en faisant partie des 93% des sites qui avaient déjà une bonne note de « FID » sur les appareils mobiles. Cependant, vous serez surpris d’apprendre que seulement 65% des sites ont un bon INP sur les appareils mobiles.
Cela démontre qu’il y avait effectivement un problème de réactivité à déceler sur les environ 28% des sites restants !
Ce chiffre montre que le Web a encore une marge de progression devant lui pour offrir encore une meilleure expérience aux utilisateurs… et c’est ce que Google souhaite nous pousser à mettre en place en nous mettant régulièrement des coups de pieds aux fesses 😀
Pour savoir si votre site a des problèmes d’INP et comment les résoudre, le meilleur endroit où commencer est notre Guide ultime d’optimisation de l’INP ➚
Que vous découvriez la réactivité pour la première fois ou que vous soyez déjà expert en performance, notre guide est rempli de nouvelles pistes visant à vous faciliter au maximum l’apprentissage de la mesure et de l’optimisation de l’INP.
Donc, depuis que l’INP remplace le FID, en ce mois de mars 2024, le rapport de la Search Console cesse d’afficher les mesures FID et utilise l’INP à la place, comme nouvelle mesure de « réactivité ». Autant s’y faire tout de suite. L’INP rejoint maintenant le Largest Contentful Paint (LCP) et le Cumulative Layout Shift (CLS) comme l’une des 3 metrics stables des Core Web Vitals.

Originaire de Belgique, Nicolas Laruelle est entrepreneur sur Internet depuis octobre 2009. Il a réalisé ses études supérieures à la Haute École de la Province de Liège. Après 7 années en tant que directeur technique de l’agence digitale Kim Communication Limited, il a officiellement fondé EasyHoster en février 2017. Plus tard, en mars 2021, offrir des solutions d’hébergement innovantes est devenu son projet principal. Depuis, EasyHoster s’est professionnalisé et a continué à croître pour atteindre la petite notoriété qu’on lui connaît aujourd’hui. De son côté, Nicolas Laruelle utilise son temps libre pour poster sur différents blogs : PROduNum, Mister WP et bien sûr, le blog EasyHoster.