TL;DR
Google a remplacé le First Input Delay (FID) par l’Interaction to Next Paint (INP) comme Core Web Vital le 12 mars 2024. Le FID mesurait uniquement le délai du navigateur avant le traitement de la première interaction de l’utilisateur. L’INP mesure le temps total entre n’importe quelle interaction de l’utilisateur — clic, toucher ou pression d’une touche — et la première réponse visuelle à l’écran, pour toutes les interactions d’une session, en indiquant la plus longue. Il est plus difficile d’obtenir un bon score INP : plus de 30 % des sites mobiles ne respectent toujours pas le seuil. Plus important encore, en 2026, les mauvais scores INP ont des répercussions qui dépassent les classements organiques. La réactivité d’une page influence directement son accessibilité pour les robots d’exploration IA — notamment GPTBot et PerplexityBot — ainsi que les signaux d’expérience utilisateur qui prédisent l’éligibilité aux citations par l’IA. Ce guide explique en détail les différences entre FID et INP et relie l’optimisation de l’INP à la couche de visibilité dans la recherche IA surveillée par Dageno AI.
Points communs entre le FID et l’INP
Les deux métriques mesurent la réactivité d’un site Web — la manière dont une page réagit aux actions des utilisateurs. Elles reposent toutes deux sur des interactions réelles : ni le FID ni l’INP ne sont enregistrés si un utilisateur ouvre une page et la lit sans cliquer, toucher l’écran ou appuyer sur une touche. Il est impossible de mesurer l’une ou l’autre de manière fiable dans un environnement de laboratoire pur en rechargeant simplement une page ; il faut simuler de véritables interactions pour obtenir des scores.
Cela les distingue du LCP (Largest Contentful Paint) et du CLS (Cumulative Layout Shift), qui sont enregistrés automatiquement au chargement de la page, quel que soit le comportement de l’utilisateur.
Les principales différences : pourquoi l’INP a remplacé le FID
1. Première interaction vs toutes les interactions
Le FID mesure uniquement la première interaction de l’utilisateur — le délai avant que le navigateur commence à traiter le tout premier clic, toucher ou appui sur une touche après le chargement de la page.
L’INP collecte des données sur chaque interaction pendant toute la session, puis indique l’interaction la plus longue — celle qui a mis le plus de temps à produire une réponse visible. Google applique une exception : si une page compte plus de 50 interactions au cours d’une session, la valeur aberrante la plus élevée est ignorée, afin d’éviter que des événements catastrophiques rares ne faussent le score. Pour la plupart des pages qui comptent moins de 50 interactions par session, l’interaction la plus longue détermine le score INP.
Exemple concret de l’évolution de l’INP au cours d’une session :
- Première interaction : 104 ms → INP = 104 ms
- Deuxième interaction : 472 ms → l’INP passe à 472 ms
- De la troisième à la dixième interaction : 16 ms–56 ms → l’INP reste à 472 ms
- L’interaction de 472 ms était la plus longue ; elle détermine l’INP de la session
2. Ce qui est réellement mesuré
Le FID mesure uniquement le délai d’entrée — le temps entre une action de l’utilisateur et le moment où le navigateur commence à la traiter. Le temps de traitement du navigateur et le rendu visuel de la réponse ne sont pas inclus dans le FID.
L’INP mesure la durée complète de l’interaction : délai d’entrée + temps de traitement + délai de présentation — soit le temps nécessaire pour que le premier changement d’image à l’écran apparaisse après l’action de l’utilisateur. L’INP indique le temps total que l’utilisateur doit attendre avant de voir qu’une action a été effectuée.
L’INP constitue donc une mesure fondamentalement plus complète de la qualité des interactions. Une page qui commence rapidement à traiter une interaction, mais met 800 ms à se mettre à jour visuellement, peut obtenir un bon score FID (délai d’entrée rapide) tout en échouant à l’INP (durée totale de l’interaction trop longue).
3. Taux de réussite et difficulté
Le passage du FID à l’INP s’explique en partie par le fait que la plupart des sites Web obtenaient déjà de bons scores FID : cette métrique ne permettait plus de suffisamment distinguer les performances. Plus de 90 % des sites Web respectaient le seuil FID, aussi bien sur mobile que sur ordinateur, ce qui en faisait un mauvais indicateur pour différencier la qualité des interactions sur le Web.
Il est nettement plus difficile d’obtenir un bon score INP. Plus de 30 % des sites mobiles ne respectent toujours pas le seuil INP, ce qui fournit un signal de différenciation plus pertinent et un véritable objectif d’optimisation pour la majorité du secteur.
4. Une approche centrée sur l’utilisateur
Le fait que le FID ne porte que sur la première interaction peut donner une image trompeuse de l’expérience utilisateur. Une page qui répond instantanément au premier clic, mais devient de plus en plus lente à mesure que l’utilisateur interagit davantage — peut-être en raison de l’accumulation de l’exécution JavaScript sur une page riche en interactions — afficherait un excellent FID tout en offrant une expérience réelle médiocre.
En mesurant toutes les interactions et en indiquant la plus longue, l’INP reflète ce que les utilisateurs vivent réellement pendant toute leur visite de la page. Il constitue ainsi un indicateur indirect plus précis de la réactivité perçue par les utilisateurs.
Les seuils INP
| Score |
Classification |
| 200 ms ou moins |
Bon |
| 201 ms–500 ms |
À améliorer |
| Plus de 500 ms |
Médiocre |
Pour obtenir un bon score INP, chaque interaction au cours d’une session doit se terminer dans les 200 ms entre l’action de l’utilisateur et la réponse visuelle. C’est beaucoup plus exigeant que le FID, pour lequel seul le délai d’entrée de la première interaction devait être rapide.
Pourquoi cela compte au-delà du SEO traditionnel : l’INP et l’accès des robots d’exploration IA
En 2026, l’optimisation des Core Web Vitals a des implications qui dépassent les classements organiques, ce qui n’était pas le cas lors de l’introduction du FID.
Selon l’analyse des robots d’exploration de Cloudflare publiée en mai 2025, la part de marché de GPTBot parmi tous les robots d’exploration est passée à 7,7 % (contre 2,2 % en mai 2024, soit +305 %) et celle de PerplexityBot a progressé de 157 490 % à partir d’une présence minimale. Avec ClaudeBot et d’autres robots d’exploration IA, le trafic des robots IA représente désormais une part importante et croissante de l’activité totale d’exploration.
Les robots d’exploration IA n’exécutent pas JavaScript. GPTBot, ClaudeBot et PerplexityBot ne traitent que le HTML statique. Les charges JavaScript importantes qui entraînent de mauvais scores INP — parce qu’elles bloquent le thread principal, retardent le traitement des événements ou créent de longues tâches qui empêchent les mises à jour visuelles en temps voulu — sont aussi celles qui risquent le plus de rendre votre contenu invisible aux robots d’exploration IA. Les mêmes optimisations JavaScript qui améliorent l’INP pour les utilisateurs réels réduisent également la charge de rendu qui conduit les robots d’exploration IA à recevoir un contenu vide ou mal formé.
Cela crée un lien direct : corriger les problèmes JavaScript à l’origine des mauvais scores INP améliore aussi l’accessibilité pour les robots d’exploration IA, qui détermine si les plateformes d’IA peuvent indexer votre contenu et ensuite le citer.
Outils de mesure de l’INP
- Google Search Console — Rapport Core Web Vitals avec des données de terrain issues de vrais utilisateurs de Chrome
- Google PageSpeed Insights — combine des données de terrain (CrUX) avec des données de laboratoire pour analyser des URL individuelles
- Chrome DevTools — panneau Performance pour analyser en détail la chronologie des interactions
- Extension Chrome Web Vitals — mesure de l’INP en temps réel lors de sessions de tests manuels
- WebPageTest — tests INP avec simulation des interactions depuis plusieurs emplacements
La distinction essentielle : l’INP est avant tout une métrique de Real User Monitoring (RUM). Les tests en laboratoire peuvent simuler des interactions, mais les scores INP affichés dans Google Search Console reflètent les comportements réels des utilisateurs, qui ne peuvent pas être entièrement reproduits par des tests synthétiques.
Relier l’INP à la visibilité dans la recherche IA : Dageno AI
L’optimisation de l’INP améliore les signaux d’expérience utilisateur qui contribuent à l’autorité d’une page — et l’autorité de la page est l’un des facteurs prédictifs de l’éligibilité aux citations par l’IA. Mais une fois vos performances techniques optimisées, vous avez toujours besoin d’une couche dédiée pour savoir si cette optimisation se traduit réellement par des citations par l’IA.
Dageno AI fournit cette couche de mesure : la plateforme suit les performances de citation de marque simultanément sur ChatGPT, Perplexity, Google AI Overviews, Google AI Mode, Gemini, Claude, Grok, Microsoft Copilot, DeepSeek et Qwen, à partir d’un tableau de bord unique.
Alors que l’optimisation de l’INP porte sur ce qui se passe lorsque des robots d’exploration IA visitent votre site (qualité du rendu JavaScript, accessibilité du contenu), l’intégration au graphe de connaissances de Dageno AI porte sur ce que les plateformes d’IA disent de votre marque lorsqu’elles le font — afin que le contenu de vos pages optimisées et performantes soit correctement représenté dans les réponses générées par l’IA.
Le lien est séquentiel : bon INP → meilleur accès pour les robots d’exploration IA → probabilité accrue d’indexation par l’IA → Dageno AI surveille si les pages indexées obtiennent des citations par l’IA → l’alignement sur le graphe de connaissances garantit l’exactitude de ces citations.
Tarification : une offre gratuite est disponible. Les offres payantes évoluent en fonction du volume de prompts et de la fréquence de surveillance.
FAQ
Dois-je encore m’intéresser au FID depuis le passage à l’INP ?
Le FID n’a plus d’incidence sur les évaluations des Core Web Vitals dans Google Search Console ni sur les signaux de classement. Il n’est donc plus nécessaire de le surveiller. Toutefois, comme le FID a toujours été une composante de l’INP (le délai d’entrée), l’optimisation de l’INP permettra naturellement de résoudre les éventuels problèmes de FID.
L’INP est-il un facteur de classement ?
Oui — l’INP fait partie des Core Web Vitals, que Google utilise comme signal de classement dans le cadre de son évaluation de l’expérience de la page. Un mauvais score INP ne garantit pas une baisse de classement, mais Google a confirmé que les Core Web Vitals servent de critère de départage lorsque les autres facteurs de classement sont similaires entre des pages.
Quelles sont les causes des mauvais scores INP ?
La plupart des mauvais scores INP sont dus à de longues tâches JavaScript sur le thread principal qui retardent le traitement des événements, à des scripts tiers lourds qui perturbent la gestion des interactions ou à des mises à jour complexes du DOM qui retardent le rendu visuel. Les mêmes optimisations qui réduisent ces problèmes — fractionnement du code, report du JavaScript non essentiel, réduction du blocage du thread principal — améliorent également l’accessibilité du contenu pour les robots d’exploration IA.
Références
- Google Search Central – Présentation de l’INP comme Core Web Vital : justification officielle du remplacement du FID, argument selon lequel il « évalue mieux la qualité de l’expérience utilisateur »
- web.dev – Interaction to Next Paint (INP) : définition complète de la métrique, seuils de 200 ms/500 ms, composantes du délai d’entrée, de traitement et de présentation, règle d’exception pour 50 interactions
- HTTP Archive / Chrome UX Report – Taux de réussite des Core Web Vitals : taux de réussite du FID supérieur à 90 % contre taux d’échec de l’INP supérieur à 30 % sur mobile, données historiques sur les tendances
- Cloudflare – De Googlebot à GPTBot (mai 2025) : part de marché de GPTBot parmi les robots d’exploration de 7,7 % (+305 %), hausse de 157 490 % pour PerplexityBot, croissance du trafic des robots IA et limites du rendu JavaScript
- web.dev – Optimiser l’INP : réduction des longues tâches, déblocage du thread principal, optimisation de l’exécution JavaScript, diagnostic de la latence entre l’interaction et l’image affichée