Core Web Vitals : comment optimiser l'INP et passer sous les 200 ms

Un site qui s'affiche vite mais qui « rame » au clic reste un mauvais site aux yeux des utilisateurs, et désormais aux yeux de Google. C'est exactement ce que l'INP a été conçu pour capturer : non plus la vitesse d'affichage, mais la réactivité réelle d'une page pendant toute la durée de la visite.

L'INP, le Core Web Vital qui a remplacé le FID en 2024

Jusqu'en mars 2024, la réactivité d'une page était mesurée par le FID (First Input Delay) : le délai entre la toute première interaction d'un visiteur, un clic, un tap, et le moment où le navigateur commençait à y répondre. Un métrique utile, mais limitée : elle ne racontait qu'un seul instant de la visite, souvent le plus favorable, et ignorait tout ce qui se passait ensuite.

L'INP (Interaction to Next Paint) a pris sa place le 12 mars 2024 comme troisième pilier officiel des Core Web Vitals, aux côtés du LCP (vitesse de chargement) et du CLS (stabilité visuelle). Sa différence fondamentale : elle observe toutes les interactions de la session, clics, appuis tactiles, saisies clavier, et retient la latence la plus représentative parmi elles, généralement proche de la pire observée. Un site peut donc afficher un excellent FID (la première interaction était rapide) tout en ayant un INP catastrophique (le formulaire devient injouable après quelques clics).

Aspect	FID (ancien)	INP (actuel)
Ce qui est mesuré	Uniquement la première interaction	Toutes les interactions de la visite
Ce qui est capturé	Le délai avant traitement de l'événement	Le délai complet jusqu'à l'affichage du résultat visuel
Seuil « bon »	≤ 100 ms	≤ 200 ms
Statut officiel	Retiré des Core Web Vitals depuis mars 2024	Core Web Vital officiel

Comment Google mesure concrètement l'INP

Pour chaque interaction, le navigateur découpe la mesure en trois temps : le délai d'entrée (le thread principal est-il déjà occupé quand l'utilisateur clique ?), le temps de traitement (durée d'exécution du gestionnaire d'événement associé), puis le délai de présentation (temps nécessaire pour peindre le résultat à l'écran, y compris via le prochain repaint du navigateur). L'INP retenu pour la page est, la plupart du temps, la plus mauvaise interaction observée pendant la visite (ou proche du 98ᵉ centile des interactions sur les sessions les plus riches en clics).

Trois seuils structurent l'évaluation, appliqués au 75^ᵉ centile des visites réelles collectées via le Chrome User Experience Report (CrUX) :

• Bon : INP ≤ 200 ms
• À améliorer : INP entre 200 ms et 500 ms
• Mauvais : INP > 500 ms

Point essentiel souvent mal compris : l'INP est une métrique de terrain (field data), calculée à partir de vraies visites sur de vrais appareils. Un audit Lighthouse en laboratoire, lui, n'a pas d'utilisateur qui clique, il ne peut donc pas produire d'INP directement. Il propose à la place un proxy, le Total Blocking Time (TBT), corrélé mais non identique. C'est pourquoi deux sites avec un excellent score Lighthouse peuvent afficher un INP terrain très différent une fois exposés à de vrais utilisateurs, sur des appareils d'entrée de gamme notamment.

Les causes les plus fréquentes d'un mauvais score

Dans l'immense majorité des audits, un INP dégradé pointe vers la même cause profonde : un thread principal saturé au moment où l'utilisateur interagit. Le navigateur ne peut traiter qu'une chose à la fois sur ce thread ; si du JavaScript tourne déjà, le clic doit attendre son tour.

50 ms c'est la durée au-delà de laquelle une tâche JavaScript est considérée comme « longue » et bloque potentiellement la réactivité perçue par l'utilisateur.

Les scripts tiers méritent une attention particulière : bannière de consentement cookies, widget de chat, pixels publicitaires ou solutions d'A/B testing s'exécutent souvent sans lien direct avec le contenu éditorial, mais occupent le même thread principal que le reste de la page. Un site éditorial peut ainsi avoir un code propre et un INP dégradé uniquement à cause de sa pile de scripts marketing.

Les leviers techniques pour passer sous les 200 ms

L'objectif n'est pas de faire disparaître le travail JavaScript, mais de le répartir pour que le thread principal reste disponible au moment où l'utilisateur clique. Voici les leviers qui ont le plus d'impact, dans un ordre de mise en œuvre réaliste.

1. Découpez les tâches longues. Toute fonction qui dépasse 50 ms d'exécution doit être fractionnée, par exemple en rendant la main au navigateur entre chaque lot de travail plutôt qu'en exécutant tout d'un bloc.
2. Différez le travail non essentiel. Ce qui n'est pas nécessaire à l'interaction immédiate (tracking, widgets secondaires, préchargements) peut être exécuté après le premier rendu, quand le navigateur est inactif.
3. Allégez les gestionnaires d'événements. Un clic ne doit déclencher que le strict nécessaire pour donner un retour visuel immédiat ; le reste du traitement peut suivre juste après.
4. Réduisez et fractionnez les bundles JavaScript. Le code splitting et le chargement à la demande évitent qu'une page charge et parse du code inutile à l'interaction en cours.
5. Auditez et limitez les scripts tiers. Chargez-les en différé, retardez leur exécution après l'interaction initiale, ou supprimez ceux dont la valeur ne justifie plus le coût de performance.
6. Évitez le travail de mise en page inutile pendant l'interaction. Regrouper les lectures et écritures du DOM, plutôt que de les alterner, réduit le temps de recalcul de la mise en page.

Ces optimisations rejoignent directement les enjeux abordés dans notre checklist SEO après une refonte de site : une refonte qui néglige la performance d'interaction peut faire chuter durablement le classement, même avec un design irréprochable. C'est également un chantier à anticiper dès la phase de conception, comme le rappelle notre article sur l'intérêt réel d'une refonte de site web.

Comment mesurer et suivre son INP dans la durée

Puisque l'INP est une métrique de terrain, son suivi ne peut pas se limiter à un audit ponctuel réalisé sur un seul appareil. Plusieurs outils complémentaires permettent de le surveiller dans la durée :

• Google Search Console, le rapport Signaux Web essentiels agrège les données CrUX par groupe d'URL et signale les pages sous le seuil des 200 ms.
• PageSpeed Insights, combine données terrain (si le volume de trafic le permet) et données de laboratoire pour un diagnostic ponctuel.
• La librairie web-vitals, permet de collecter l'INP réel de vos visiteurs et de l'envoyer vers votre outil d'analytics, pour un suivi continu et segmenté par appareil ou par page.
• Le panneau Performance de Chrome DevTools, utile pour identifier précisément quelle tâche ou quel script bloque le thread principal lors d'une interaction spécifique.

Un score Lighthouse parfait ne garantit rien sur l'INP réel : seules les données de vos visiteurs, sur leurs propres appareils, disent si votre site répond vraiment vite.

Dans la pratique, mieux vaut prioriser les pages à fort trafic ou à fort enjeu de conversion (fiches produit, formulaires, tunnels d'achat) plutôt que de chercher un score uniforme sur l'ensemble du site. C'est souvent là que la réactivité perçue a le plus d'impact, à la fois sur l'expérience utilisateur et, indirectement, sur le référencement.