INP, le nouveau critère de performance qui compte vraiment
Depuis mars 2024, l’INP (Interaction to Next Paint) a officiellement remplacé le FID (First Input Delay) dans le trio des Core Web Vitals de Google. Ce changement n’est pas anodin : là où le FID ne mesurait que la latence du premier clic, l’INP évalue la réactivité globale d’une page tout au long de la session utilisateur. Autrement dit, chaque fois qu’un visiteur clique sur un bouton, déplie un menu ou remplit un formulaire, l’INP enregistre le délai entre cette action et la mise à jour visuelle correspondante. Pour les agences SEO françaises qui accompagnent des clients sur des sites à fort trafic, c’est une métrique bien plus révélatrice de l’expérience réelle des internautes. Un site peut très bien afficher un bon FID historique tout en souffrant d’une interactivité catastrophique sur ses composants secondaires — et c’est précisément ce que l’INP vient corriger.
Les seuils à connaître et ce qu’ils signifient concrètement
Google a défini trois paliers pour l’INP : un score inférieur à 200 millisecondes est considéré comme « bon », entre 200 et 500 ms il faut « améliorer », et au-delà de 500 ms la page est jugée « mauvaise ». Ces seuils peuvent sembler abstraits, mais ils correspondent à des ressentis utilisateurs bien réels. En dessous de 200 ms, l’interaction paraît instantanée. Entre 200 et 500 ms, une légère hésitation devient perceptible, surtout sur mobile. Au-delà de 500 ms, l’utilisateur a clairement l’impression que la page « rame » — et il n’hésite pas à la quitter. Pour les e-commerçants français notamment, chaque dixième de seconde perdu sur une page produit ou un tunnel d’achat se traduit directement en taux de conversion dégradé. L’enjeu SEO est donc double : satisfaire l’algorithme de Google d’un côté, et retenir les visiteurs de l’autre. Ces deux objectifs convergent ici parfaitement.
Les outils disponibles pour diagnostiquer l’INP
Avant de corriger, il faut mesurer — et la bonne nouvelle, c’est que l’écosystème d’outils s’est bien étoffé depuis l’introduction officielle de l’INP. Côté données de terrain (RUM, Real User Monitoring), le rapport d’expérience utilisateur Chrome (CrUX) reste la référence : il reflète ce que vivent réellement les internautes qui utilisent Chrome sur votre site. Vous y accédez via Google Search Console, dans la section « Expérience de la page », ou directement via le tableau de bord CrUX sur Looker Studio. Ces données sont précieuses car elles représentent un agrégat de vraies sessions, pas des simulations de laboratoire. Pour des mesures en temps réel et plus granulaires, la bibliothèque JavaScript web-vitals.js de Google permet d’envoyer les valeurs INP vers votre propre système d’analytics ou vers un outil comme Google Analytics 4. C’est une approche recommandée pour les agences qui veulent construire des reportings personnalisés pour leurs clients.
Côté tests en laboratoire, PageSpeed Insights et Lighthouse restent incontournables pour obtenir une photographie rapide d’une URL. Attention cependant : Lighthouse mesure le TBT (Total Blocking Time), qui est un proxy de l’INP mais pas l’INP lui-même. Pour aller plus loin, le panneau Performance de Chrome DevTools est votre meilleur allié : il vous permet d’enregistrer une session d’interaction, d’identifier précisément les tâches longues (Long Tasks) qui bloquent le thread principal, et de visualiser les phases qui composent une interaction INP — à savoir le délai d’entrée (input delay), le temps de traitement (processing time) et le délai de présentation (presentation delay). Des extensions comme Web Vitals (disponible sur le Chrome Web Store) affichent également l’INP en temps réel pendant votre navigation, ce qui peut suffire pour un premier diagnostic rapide.
Les causes fréquentes d’un mauvais INP et comment les traiter
Une fois le diagnostic posé, encore faut-il comprendre d’où vient le problème. Dans la grande majorité des cas, un INP élevé s’explique par un thread principal surchargé. JavaScript est le premier suspect : des scripts tiers (chatbots, pixels publicitaires, outils d’A/B testing), des gestionnaires d’événements mal optimisés ou des frameworks JavaScript lourds peuvent générer des Long Tasks qui retardent la réponse visuelle. La première piste à explorer est donc la réduction du JavaScript inutile : audit des scripts tiers, chargement différé (lazy loading), découpage du code en chunks plus petits via le code splitting. Pour les sites construits avec des CMS comme WordPress, les plugins peuvent rapidement devenir un gouffre à performances — une revue régulière de la liste des extensions actives est une bonne hygiène de base.
La deuxième cause fréquente concerne le rendu et les mises à jour du DOM. Lorsqu’une interaction déclenche de nombreuses modifications dans le document HTML — recalculs de styles, reflows, repaints — le navigateur peut prendre un temps considérable avant d’afficher le résultat visible. Des techniques comme la virtualisation des listes longues, l’utilisation de content-visibility: auto en CSS ou encore le report des mises à jour non critiques via requestAnimationFrame permettent de réduire significativement ce délai de présentation. Enfin, pour les interactions déclenchées au clic ou au toucher, il est conseillé de s’assurer que les gestionnaires d’événements sont aussi légers que possible : si une opération lourde doit être effectuée, elle doit être déportée dans un Web Worker ou découpée en microtâches grâce à scheduler.yield(), une API relativement récente mais déjà bien supportée dans Chrome.
Intégrer l’INP dans une démarche d’amélioration continue
Pour les agences SEO françaises, l’INP ne doit pas être traité comme un chantier ponctuel mais comme un indicateur à surveiller en continu. L’une des erreurs classiques consiste à optimiser une page en conditions de laboratoire, observer une amélioration sur PageSpeed Insights, et considérer le sujet clos — alors que les données terrain CrUX peuvent rester dégradées pendant plusieurs semaines, le temps que la fenêtre glissante de 28 jours se mette à jour. Il est donc essentiel de mettre en place un monitoring RUM pérenne, idéalement couplé à des alertes automatiques lorsqu’un seuil critique est franchi. Des outils comme Sentry, Datadog ou des solutions plus spécialisées comme SpeedCurve permettent ce type de suivi en production.
Il faut également sensibiliser les équipes de développement de vos clients à l’impact de chaque nouvelle fonctionnalité sur les Core Web Vitals. Un composant JavaScript ajouté sans audit préalable peut faire basculer un site du vert au rouge en quelques jours. Intégrer des tests de performance dans les pipelines CI/CD — via Lighthouse CI par exemple — est une pratique qui commence à se démocratiser en France, notamment dans les ESN et les agences digitales qui travaillent sur des projets à grande échelle. L’INP devient ainsi un KPI à part entière dans les bilans mensuels, au même titre que le positionnement ou le trafic organique. C’est peut-être là sa principale valeur ajoutée pour les professionnels du SEO : transformer une contrainte technique en argument mesurable et actionnable.
