INP Core Web Vitals 2026 :
le signal que vous ignorez peut-être

L’INP (Interaction to Next Paint) est une métrique Core Web Vitals qui mesure le temps entre une interaction utilisateur (clic, tap, pression de touche) et la réponse visuelle du navigateur. Contrairement au FID qui ne mesurait que la première interaction, l’INP évalue toutes les interactions sur votre page.

Google retient le pire cas au 98ème percentile pour calculer votre score INP. Cela signifie que même une seule interaction très lente sur votre page peut dégrader significativement votre score global. Le seuil pour être considéré comme bon est de 200 millisecondes maximum, ce qui représente la limite à partir de laquelle l’utilisateur ne perçoit plus de latence.

Le FID (First Input Delay) ne mesurait que le délai de la toute première interaction de l’utilisateur sur la page. C’était une métrique imparfaite car elle ignorait toutes les interactions suivantes. Un site pouvait avoir un excellent FID mais être extrêmement lent sur les clics et scrolls ultérieurs.

L’INP corrige cette limitation en capturant la latence de chaque interaction sur la page. Il représente donc beaucoup mieux l’expérience utilisateur réelle. Google a commencé à utiliser l’INP comme signal de classement en mars 2024, et son poids a été augmenté lors de la mise à jour de mars 2026 pour atteindre le même niveau d’importance que le LCP et le CLS.

Le moyen le plus fiable est Google Search Console dans la section Core Web Vitals. Vous y trouverez une répartition de vos pages en trois catégories : Bon, À améliorer, et Mauvais. Ces données proviennent du Chrome User Experience Report qui agrège les mesures réelles de vos visiteurs utilisant Chrome.

Vous pouvez aussi utiliser PageSpeed Insights pour tester une page spécifique. Si les données de terrain CrUX sont disponibles, vous verrez votre score INP réel. Sinon, vous n’aurez que les données de laboratoire simulées qui ne sont pas utilisées par Google pour le ranking. La Web Vitals Extension Chrome permet également de voir l’INP en temps réel pendant que vous naviguez sur votre site.

Google définit trois seuils pour l’INP : Bon si inférieur ou égal à 200 millisecondes, À améliorer entre 200 et 500 millisecondes, et Mauvais au-dessus de 500 millisecondes. Le seuil de 200ms correspond à la limite à partir de laquelle l’utilisateur perçoit un délai de réponse.

Pour le SEO, visez toujours un INP inférieur à 200ms sur toutes vos pages importantes. Les données montrent que 43% des sites échouent actuellement ce seuil, ce qui représente une opportunité de différenciation pour ceux qui l’optimisent. Un INP entre 200 et 500ms ne vous pénalisera pas sévèrement, mais vous n’aurez pas le bonus positif des sites vraiment rapides.

Les causes les plus fréquentes d’un mauvais INP sont liées au JavaScript. Les scripts tiers comme les analytics, widgets de chat et pixels publicitaires bloquent souvent le thread principal du navigateur. Les frameworks JavaScript comme React ou Vue peuvent aussi causer des problèmes s’ils ne sont pas optimisés pour le code splitting.

D’autres causes incluent les gestionnaires d’événements trop lourds qui exécutent trop de code à chaque clic, les polyfills et bibliothèques legacy qui alourdissent l’exécution, et un DOM trop volumineux avec plus de 1500 éléments qui ralentit le rendering. L’identification de la cause exacte nécessite généralement un audit avec les Chrome DevTools Performance.

Sur WordPress, les principales sources de problèmes INP sont les plugins qui ajoutent du JavaScript sur le frontend. Commencez par identifier les plugins qui chargent des scripts sur chaque page via le panel Network des DevTools. Désactivez ou remplacez les plugins les plus lourds par des alternatives plus légères.

Utilisez un plugin de cache comme WP Rocket qui permet de différer le chargement du JavaScript non essentiel. Activez les options de lazy loading pour les images et les iframes. Évitez les page builders lourds comme Elementor sur les pages critiques, ou utilisez leurs fonctionnalités d’optimisation. Enfin, limitez le nombre de scripts tiers de tracking et marketing au strict nécessaire.

Oui, l’INP est un signal de classement officiel depuis mars 2024, et son importance a été renforcée lors de l’update de mars 2026. Google l’intègre dans le Page Experience signal qui contribue aux classements. Cependant, l’INP seul ne détermine pas vos positions : un site avec un excellent contenu et un mauvais INP peut encore bien se positionner.

L’impact SEO de l’INP est indirect mais réel. Un site lent augmente le taux de rebond et réduit l’engagement, qui sont des signaux utilisateur négatifs. Les études montrent que les sites avec un INP supérieur à 500ms perdent entre 8 et 35% de conversions. Optimisez l’INP d’abord pour l’expérience utilisateur, le bénéfice SEO suivra naturellement.

Les données de terrain (field data) proviennent de vrais utilisateurs naviguant sur votre site avec Chrome. Elles sont collectées via le Chrome User Experience Report et reflètent les performances réelles expérimentées par vos visiteurs. Ce sont ces données que Google utilise pour le ranking.

Les données de laboratoire (lab data) sont simulées par des outils comme Lighthouse dans des conditions contrôlées. Elles sont utiles pour le diagnostic technique car elles sont reproductibles, mais elles ne représentent pas forcément l’expérience utilisateur réelle. Pour le SEO, concentrez-vous sur l’amélioration des données de terrain, même si les données de laboratoire peuvent vous aider à identifier les problèmes.

Le temps nécessaire dépend de la complexité de votre site et des causes du problème. Pour un site simple avec quelques scripts tiers à optimiser, comptez 1 à 2 semaines. Pour un site e-commerce ou SaaS avec beaucoup de JavaScript custom, comptez 3 à 6 semaines pour des améliorations significatives.

Une fois les optimisations déployées, comptez encore 28 jours pour voir les résultats dans Search Console. C’est le temps nécessaire pour que Google collecte suffisamment de données CrUX auprès de vos visiteurs. Si votre site a peu de trafic Chrome, la mise à jour des données peut prendre encore plus longtemps. Patience et monitoring sont essentiels.

Oui, c’est possible si les scripts sont chargés intelligemment. La clé est de différer le chargement des scripts non critiques après l’interaction initiale de l’utilisateur. Utilisez les attributs async et defer pour les scripts, et les techniques comme requestIdleCallback pour charger les fonctionnalités secondaires pendant les temps morts du navigateur.

J’ai des clients avec 15 à 20 scripts tiers qui maintiennent un INP sous 150ms grâce à une orchestration soignée. La stratégie consiste à identifier quels scripts sont vraiment nécessaires au chargement initial (souvent moins qu’on ne le pense), et à différer tout le reste. Un audit régulier de vos scripts tiers est recommandé car ils évoluent et peuvent devenir plus lourds avec le temps.