INP SEO : comprendre et optimiser l’Interaction to Next Paint

L’INP (Interaction to Next Paint) mesure la réactivité de votre page à chaque interaction : clic, tap sur écran tactile ou frappe au clavier. Il a remplacé le FID (First Input Delay) le 12 mars 2024 au sein des Core Web Vitals de Google. Un bon score se situe sous 200 ms au 75^e percentile de vos visiteurs réels — au-delà, votre page est signalée comme lente à réagir.

Concrètement, si votre rapport « Expérience sur la page » vient de passer au rouge dans la Search Console, l’INP en est souvent la cause. Et pour une raison simple : là où le FID fermait les yeux sur tout sauf le premier clic, l’INP observe l’ensemble de vos interactions et retient la plus lente. Une page pouvait afficher un FID excellent tout en gelant à l’ouverture d’un menu, à l’application d’un filtre ou à l’envoi d’un formulaire — l’INP, lui, ne laisse plus rien passer. Ce guide vous explique ce qu’est réellement l’INP, pourquoi Google a durci ce signal, quels seuils respecter en 2026, comment le mesurer avec les bons outils, et surtout où votre hébergeur agit vraiment — et où il ne peut rien pour vous. Toutes les données et offres citées ont été vérifiées en juillet 2026.

Qu’est-ce que l’INP (Interaction to Next Paint) ?

L’INP est la métrique qui note la rapidité de réaction visible de votre page. À chaque fois qu’un visiteur interagit, le navigateur doit répondre en affichant un retour à l’écran — le menu qui s’ouvre, le produit qui s’ajoute au panier, la case qui se coche. L’INP mesure le délai entre l’action et ce retour visuel. Pour vous, cela veut dire une chose : plus votre INP est bas, plus votre site donne une impression de solidité et de fiabilité, ce qui limite les abandons.

Point important pour votre diagnostic : l’INP ne retient pas la moyenne de vos interactions, mais la plus lente (ou presque) sur toute la visite. Un seul point de friction récurrent — un bouton lourd, un filtre mal optimisé — suffit donc à dégrader votre score. Corriger votre INP revient à traquer votre pire interaction, pas à lisser une moyenne rassurante.

À noter également : le défilement et le zoom ne sont pas comptés (source : MDN Web Docs). Ils sont gérés par un autre fil d’exécution du navigateur et ne bloquent pas la réactivité mesurée. Vous pouvez donc concentrer vos efforts sur les vraies interactions : clics, taps et saisies clavier.

Les trois temps d’une interaction : input delay, processing time, presentation delay

Chaque interaction se décompose en trois phases (source : web.dev, Google). Savoir laquelle pèse le plus vous évite d’optimiser au hasard :

• Input delay (délai d’entrée) → le temps d’attente avant que le navigateur ne commence à traiter votre clic, souvent parce que le fil principal est déjà occupé. Ce que ça vous apporte de le savoir : c’est la seule phase où votre hébergeur et un serveur bien configuré peuvent réellement aider.
• Processing time (temps de traitement) → le temps d’exécution du code JavaScript déclenché par l’interaction. Pour vous : c’est ici que se cachent la majorité des ralentissements, généralement dus à un thème lourd, à des extensions ou à des scripts tiers.
• Presentation delay (délai d’affichage) → le temps que met le navigateur à peindre le résultat à l’écran (recalcul de mise en page, rendu). Pour vous : une interface qui déclenche de gros recalculs de layout à chaque clic paiera cette phase au prix fort.

En clair, un INP dégradé est le plus souvent un problème de processing time et de presentation delay — donc de code côté client — bien plus que de serveur. Cette distinction, nous la creusons plus loin, car elle change radicalement vos priorités d’action.

Pourquoi Google a-t-il remplacé le FID par l’INP ?

Le FID (First Input Delay) a rendu service pendant des années, mais il souffrait de deux limites qui en faisaient une mesure incomplète de la réactivité (source : web.dev, Google).

• Première limite : il ne mesurait que la première interaction. Si votre premier clic était rapide, le FID validait votre page — même si toutes les interactions suivantes étaient lentes. Un site pouvait donc afficher un score parfait tout en devenant pénible dès qu’on utilisait un filtre ou un formulaire.
• Seconde limite : il ne mesurait que le délai d’entrée (input delay). Le FID s’arrêtait au moment où le navigateur commençait à traiter l’événement. Il ignorait le temps d’exécution du code (processing time) et le temps d’affichage du résultat (presentation delay) — c’est-à-dire l’essentiel de ce que ressent réellement l’utilisateur.

L’INP corrige ces deux angles morts : il observe toutes les interactions de la visite et couvre les trois phases de chacune. Le résultat est un signal bien plus fidèle à l’expérience vécue, mais aussi bien plus difficile à valider.

Ce durcissement a eu un effet concret et mesurable. Lors de la bascule de mars 2024, le taux de sites obtenant un « bon » score aux Core Web Vitals sur mobile a reculé d’environ 5 points (source : HTTP Archive – Web Almanac 2025). La raison : de nombreux sites qui paraissaient réactifs sous le FID cachaient en réalité des interactions tardives, que l’INP a immédiatement révélées. En 2026, l’INP reste le Core Web Vital le plus difficile à passer : selon les données CrUX, environ 40 à 43 % des origines échouent encore au seuil sur mobile (sources : SitePoint, DigitalApplied).

Pour vous, la leçon est simple : un bon score hérité de l’époque du FID ne vous protège plus. Il faut désormais vérifier la réactivité de chaque parcours d’interaction sur vos pages clés.

Cas concret : un e-commerçant WooCommerce face à un INP dans le rouge

Un e-commerçant gère une boutique WooCommerce sur un hébergement mutualisé, avec environ 15 000 visites par mois. Site fonctionnel, design soigné, mais rapport « Expérience sur la page » passé au rouge dans la Search Console.

l’INP est mesuré à 380 ms au 75^e percentile — soit dans la zone « à améliorer », proche du seuil médiocre. Le point de friction se concentre sur le clic « ajouter au panier », qui déclenche plusieurs scripts (suivi analytique, widget d’avis, chat) avant d’afficher la confirmation.

Action : trois leviers activés dans l’ordre. D’abord le poste le plus lourd — le code : les scripts tiers non essentiels sont différés ou chargés après interaction. Ensuite le serveur : le cache serveur est activé et la version de PHP est passée à une version 8.x récente, ce qui allège le rendu et libère plus tôt le fil principal. Enfin, mesure sur le terrain via CrUX, et non en laboratoire.

l’INP repasse sous 200 ms au 75^e percentile, et la page sort du rouge dans la Search Console après la fenêtre de 28 jours utilisée par Google pour consolider les données réelles.

Ce que ce cas illustre : l’essentiel du gain est venu du code (scripts tiers), le serveur ayant joué un rôle de soutien réel mais secondaire. C’est l’ordre de priorité à retenir pour votre propre diagnostic.

Quels sont les seuils INP à respecter en 2026 ?

Google classe l’INP en trois zones, mesurées au 75^e percentile des visiteurs réels (source : web.dev).

Trois précisions changent tout dans l’interprétation de ce tableau.

• Le 75^e percentile, pas la moyenne → 75 % de vos visiteurs réels doivent vivre une interaction sous 200 ms. Une moyenne rassurante peut masquer un quart d’utilisateurs en souffrance, notamment sur mobile d’entrée de gamme.
• Une fenêtre glissante de 28 jours → Google consolide les données sur près d’un mois (source : CrUX / web.dev). Impact concret : après une correction, ne vous attendez pas à un changement immédiat de votre score — comptez plusieurs semaines avant de voir le résultat.
• Données de terrain, pas de laboratoire → c’est le point qui égare le plus de propriétaires de site. Un excellent score Lighthouse ne garantit rien : Lighthouse simule un environnement contrôlé, alors que Google juge sur les vrais appareils de vos vrais visiteurs. Impact : fiez-vous en priorité à CrUX, PageSpeed Insights (section données réelles) et à la Search Console.

Ces trois éléments expliquent pourquoi tant de sites restent dans le rouge malgré des tests locaux flatteurs — et pourquoi l’INP demeure, en 2026, le Core Web Vital le plus difficile à valider. Pour situer l’INP par rapport aux deux autres signaux (LCP et CLS), consultez notre analyse des Core Web Vitals en 2026.

INP et hébergeur : quelle corrélation réelle ?

C’est la question qui revient le plus souvent — et celle sur laquelle la plupart des contenus restent vagues. La réponse honnête tient en une phrase : votre hébergeur influence une partie de votre INP, mais pas la partie la plus lourde.

Reprenons les trois phases de l’interaction et voyons où l’infrastructure agit réellement.

Le constat est net : deux phases sur trois échappent totalement à votre hébergeur. C’est pour cette raison qu’un site hébergé sur une infrastructure haut de gamme peut afficher un INP catastrophique s’il embarque un constructeur de pages lourd et une dizaine de scripts tiers.

Cela ne veut pas dire que l’hébergement est neutre. Un mutualisé sous-dimensionné, saturé aux heures de pointe, allonge le temps de rendu de vos pages et laisse le navigateur plus longtemps occupé au moment où votre visiteur clique. À l’inverse, un hébergement correctement équipé — PHP 8.x, OPcache, cache serveur (LWSCache, Varnish ou LiteSpeed), stockage NVMe, HTTP/3 — réduit ce délai initial. Pour aller plus loin, consultez notre mesure du TTFB des hébergeurs français.

Faut-il changer d’hébergeur pour améliorer son INP ?

Dans la majorité des cas : non, pas en première intention. Migrer avant d’avoir allégé votre JavaScript revient à payer une amélioration marginale sans traiter la cause principale. La bonne séquence est l’inverse : corrigez d’abord le code, puis évaluez si votre serveur constitue encore un frein.

Selon votre niveau technique et votre budget, la première action reste donc gratuite : vérifiez dans votre panneau d’administration si votre version de PHP est à jour et si le cache serveur est bien activé. Beaucoup de sites tournent encore sur des configurations par défaut sous-exploitées.

Comment mesurer son INP ?

Il n’existe pas un outil unique, mais deux familles d’outils complémentaires — et confondre les deux est l’erreur de diagnostic la plus courante.

Les outils de terrain (données réelles — ce que Google juge)

• PageSpeed Insights → affiche votre INP réel issu du rapport CrUX, dans la section consacrée aux utilisateurs réels. C’est votre point de départ : si cette section est verte, votre INP est validé aux yeux de Google.
• Search Console — rapport « Expérience sur la page » → identifie les groupes d’URL concernés par un INP médiocre. Utile pour savoir si le problème touche un modèle de page (fiches produit, articles) ou l’ensemble du site.
• CrUX Dashboard → données agrégées sur 28 jours, segmentées par type d’appareil. Indispensable pour vérifier si le problème est spécifique au mobile — c’est presque toujours le cas.
• Une solution RUM (Real User Monitoring) → attribue l’INP à une interaction précise. Bénéfice concret : vous savez quel bouton pose problème, au lieu de deviner.

Les outils de laboratoire (reproduction et diagnostic)

• Chrome DevTools → onglet Performance → enregistrez une interaction, puis repérez les tâches longues sur le fil principal. La piste « Interactions » décompose input delay, processing time et presentation delay. C’est ici que vous identifiez quelle phase est fautive.
• Extension Web Vitals → affiche l’INP en temps réel pendant votre navigation. Pratique pour un contrôle rapide, insuffisant pour un diagnostic complet.

La règle à retenir : partez toujours des données de terrain pour savoir si vous avez un problème, puis passez en laboratoire pour comprendre pourquoi. L’inverse vous fera optimiser des pages qui n’en avaient pas besoin.

Un dernier point souvent négligé : votre site doit être inclus dans le jeu de données CrUX pour disposer de données de terrain. Les sites à faible trafic n’y figurent pas toujours — dans ce cas, une solution RUM ou une mesure DevTools sur vos parcours clés reste votre seule option fiable.

Comment améliorer concrètement son INP ?

Les leviers ne se valent pas. Voici l’ordre de priorité qui produit le meilleur retour sur effort, du plus impactant au plus accessoire.

1. Côté code : l’essentiel du gain

C’est ici que se joue la majorité de votre score, via le processing time.

• Fractionnez les tâches longues → toute tâche JavaScript qui occupe le fil principal plus de 50 ms bloque les interactions. En la découpant, vous rendez la main au navigateur entre chaque bloc. Bénéfice : le bouton répond immédiatement, même si le traitement se poursuit en arrière-plan.
• Différez les scripts tiers non critiques → chat, widgets d’avis, suivi analytique, pixels publicitaires. Chargez-les après l’affichage initial, ou seulement après une première interaction.
• Allégez le thème et les extensions → sur WordPress, les constructeurs de pages sont la première cause d’INP dégradé. Selon votre niveau technique, désactivez les modules inutilisés ou envisagez un thème plus sobre sur vos modèles de pages critiques.
• Réduisez le volume de JavaScript envoyé → moins de code à analyser et exécuter, moins de fil principal occupé.

2. Côté rendu : limiter le presentation delay

• Évitez les recalculs de mise en page coûteux à chaque interaction (modification de largeur, hauteur, position).
• Privilégiez les propriétés CSS transform et opacity pour les animations : elles n’entraînent pas de recalcul complet de la mise en page.
• Isolez les zones de la page avec contain: layout ou content-visibility: auto sur les sections hors écran.

3. Côté serveur : l’appui indirect

Ces réglages réduisent l’input delay en libérant plus tôt le fil principal.

• Passez à une version de PHP récente (8.x) → traitement plus rapide, rendu serveur allégé.
• Vérifiez qu’OPcache est actif → le code PHP compilé est conservé en mémoire, ce qui évite de le recompiler à chaque requête.
• Activez le cache serveur (LWSCache, Varnish, LiteSpeed selon votre hébergeur) → les pages sont servies sans reconstruction complète.
• Vérifiez le stockage NVMe et le support HTTP/3 sur votre offre.

⚠️ À ne pas confondre : ces optimisations serveur améliorent surtout votre TTFB et votre LCP. Leur effet sur l’INP est réel mais secondaire — ne les traitez jamais en substitut du travail sur le JavaScript.

Votre checklist de correction en 5 étapes

1. Mesurez sur le terrain → PageSpeed Insights ou CrUX, pour identifier les URL réellement concernées.
2. Reproduisez l’interaction fautive → Chrome DevTools, onglet Performance, piste Interactions.
3. Isolez la phase dominante → input delay, processing time ou presentation delay.
4. Corrigez en priorité la phase identifiée → et elle seule, pour mesurer l’effet réel de votre action.
5. Re-mesurez après 28 jours → sur les données de terrain, jamais en laboratoire.

Conclusion

L’INP a changé la nature du signal de réactivité. Là où le FID se contentait d’un premier clic rapide, l’Interaction to Next Paint observe toutes vos interactions et retient la plus lente — clic, tap, saisie clavier. Le seuil est connu et non négociable : moins de 200 ms au 75^e percentile de vos visiteurs réels, mesuré sur une fenêtre de 28 jours.

Ce que cet article vous a montré tient en une hiérarchie simple. Votre INP se joue d’abord dans votre code — JavaScript, thème, extensions, scripts tiers — qui pilote le processing time et le presentation delay. Votre hébergeur, lui, agit sur une seule des trois phases : l’input delay. C’est une contribution réelle, mais partielle. Un serveur bien configuré ne compensera jamais un constructeur de pages surchargé.

La démarche à suivre est donc toujours la même, quel que soit votre profil : mesurez sur le terrain, isolez la phase fautive en laboratoire, corrigez la cause dominante, puis re-mesurez après 28 jours. Traiter l’INP dans cet ordre vous évite deux erreurs coûteuses — optimiser au hasard, et migrer vers un nouvel hébergeur pour un problème qui n’était pas le sien.

Cela dit, si votre code est déjà propre et que votre rendu serveur reste lent, la question de l’hébergement devient légitime. Selon votre budget et vos besoins, un hébergement doté d’une version de PHP récente, d’OPcache et d’un cache serveur actif vous fera gagner sur l’input delay — et, au passage, sur votre LCP.

Vous préférez comparer avant de choisir ? Consultez notre benchmark des hébergeurs français ou notre classement des hébergeurs les plus rapides.

FAQ — Interaction to Next Paint (INP)

L’INP (Interaction to Next Paint) est un Core Web Vital qui mesure la réactivité d’une page à chaque interaction : clic, tap sur écran tactile ou frappe clavier. Il évalue le délai entre l’action de l’utilisateur et l’affichage du retour visuel à l’écran. Un bon score est inférieur à 200 ms au 75^e percentile. Le défilement et le zoom ne sont pas comptabilisés.

Commencez par les données de terrain : PageSpeed Insights (section utilisateurs réels), le rapport « Expérience sur la page » de la Search Console ou le CrUX Dashboard. Ces outils vous disent si vous avez un problème. Passez ensuite en laboratoire avec Chrome DevTools (onglet Performance, piste Interactions) pour comprendre pourquoi — c’est là que vous identifiez la phase fautive.

Seul l’INP compte. Le FID (First Input Delay) a été retiré des Core Web Vitals le 12 mars 2024 et n’est plus utilisé par les outils de Google. Il ne mesurait que la première interaction, et uniquement son délai d’entrée. L’INP observe toutes les interactions et couvre les trois phases de chacune, ce qui en fait un signal bien plus fidèle — et plus exigeant.

Non. Votre hébergeur n’agit que sur une des trois phases de l’INP, l’input delay : un rendu serveur rapide (PHP récent, OPcache, cache serveur) libère plus tôt le fil principal du navigateur. Les deux autres phases — processing time et presentation delay — dépendent entièrement de votre code. Un site hébergé sur une infrastructure haut de gamme peut afficher un INP médiocre s’il embarque un thème lourd et de nombreux scripts tiers.

Le TTFB (Time To First Byte) mesure le temps de réponse de votre serveur. Ce n’est pas un Core Web Vital : c’est une métrique de diagnostic, qui pèse surtout sur votre LCP. L’INP, lui, mesure la réactivité de votre interface après le chargement. Un bon TTFB ne garantit donc pas un bon INP.

Non. Le défilement et le zoom sont exclus du calcul de l’INP (source : MDN Web Docs). Ils sont gérés par un autre fil d’exécution du navigateur et ne bloquent pas la réactivité mesurée. Seuls les clics, les taps et les frappes clavier sont pris en compte.

Oui, en tant que composante des Core Web Vitals, qui font partie des signaux d’expérience de page. Son poids reste modéré comparé à la pertinence du contenu : un INP excellent ne fera pas remonter une page sans valeur. En revanche, à contenu équivalent, une page qui réagit vite conserve un avantage — sur le classement comme sur le taux de conversion.

Comptez environ 28 jours. Google consolide les Core Web Vitals sur une fenêtre glissante de 28 jours à partir des données réelles (CrUX). Après une correction, votre score en laboratoire s’améliorera immédiatement, mais votre statut dans la Search Console ne changera qu’une fois la fenêtre renouvelée.