INP Google : optimiser la réactivité de votre site

Votre site affiche un excellent score de vitesse de chargement, mais vos visiteurs se plaignent quand même que le site « rame » dès qu'ils cliquent sur un bouton ou remplissent un formulaire. Ce n'est pas une contradiction : Google mesure ce phénomène avec une métrique à part, l'INP (Interaction to Next Paint), distincte du temps de chargement. En 2025, seuls 77 % des sites mobiles obtiennent encore un bon score INP (HTTP Archive, 2025), ce qui en fait la métrique la plus difficile à corriger parmi les trois Core Web Vitals.

À Retenir

• L'INP mesure la réactivité d'un site à chaque clic, tape ou saisie clavier, pas seulement le temps de chargement initial
• Seuil « bon » : 200 millisecondes ou moins, mesuré au 75e percentile des visites réelles (web.dev, 2026)
• En 2025, 77 % des sites mobiles passent ce seuil, contre 97 % sur desktop (HTTP Archive, 2025)
• Une « Long Task » est une tâche JavaScript qui bloque le navigateur plus de 50 millisecondes (web.dev, 2026)

Qu'est-ce que l'INP et pourquoi Google en a-t-il fait une métrique officielle ?

L'INP évalue la réactivité globale d'une page en observant la latence de tous les clics, taps et saisies clavier qui se produisent pendant toute la durée de la visite d'un utilisateur (web.dev, 2026). Contrairement à une métrique de vitesse de chargement, elle ne s'arrête pas une fois la page affichée : elle continue de mesurer chaque interaction, du premier clic au dernier.

Google a officiellement remplacé le First Input Delay (FID) par l'INP en mars 2024, un changement qui n'est pas anodin. Le FID ne mesurait que le délai de la toute première interaction sur une page. L'INP, lui, observe l'ensemble du parcours utilisateur : le délai d'entrée, le temps d'exécution du gestionnaire d'événement et le délai de présentation à l'écran. Cette approche plus complète se justifie par un constat simple de Google : 90 % du temps qu'un utilisateur passe sur une page se déroule après son chargement initial (web.dev, 2026). Autrement dit, l'essentiel de l'expérience se joue une fois que la page est déjà là, pas pendant qu'elle apparaît.

Le score est mesuré au 75e percentile des interactions réelles de vos visiteurs, séparément pour mobile et desktop. Trois seuils s'appliquent : 200 millisecondes ou moins pour un score « bon », entre 200 et 500 millisecondes pour « à améliorer », et au-delà de 500 millisecondes pour « mauvais » (web.dev, 2026).

LCP vs INP : quelle différence entre les deux métriques ?

Le LCP (Largest Contentful Paint) et l'INP répondent à deux questions complètement différentes, et notre guide sur les Core Web Vitals détaille le LCP en profondeur. Pour résumer la distinction : le LCP demande « combien de temps avant que la page semble chargée ? », tandis que l'INP demande « combien de temps avant que la page réponde quand j'interagis avec elle ? ».

Un site peut parfaitement afficher un LCP excellent, sous la seconde, et un INP catastrophique. C'est même une situation fréquente sur les sites qui misent tout sur l'optimisation des images et du cache, sans se soucier du JavaScript qui s'exécute après le chargement. Un menu qui met une demi-seconde à réagir au clic, un formulaire qui se fige quelques instants après la saisie d'un champ : ce sont des symptômes typiques d'un mauvais INP, invisibles dans un test de vitesse classique.

Cette distinction compte particulièrement pour les sites avec des éléments interactifs riches : formulaires de devis, filtres de recherche, configurateurs de produits, chats en ligne. Ce sont précisément les fonctionnalités qui génèrent le plus de conversions pour une PME, et celles où un mauvais INP se paie le plus cher en abandon de parcours.

Quelles sont les trois phases d'une interaction lente ?

Chaque interaction mesurée par l'INP se décompose en trois phases distinctes, et comprendre laquelle pose problème sur votre site change entièrement la correction à apporter (web.dev, 2026) :

1. Le délai de saisie (input delay) : le temps entre le moment où l'utilisateur clique et le moment où le navigateur commence réellement à exécuter le code qui doit répondre à ce clic. Ce délai grimpe quand le thread principal est occupé par autre chose, souvent du JavaScript qui s'exécute au démarrage de la page.
2. La durée de traitement (processing duration) : le temps que prend le code lui-même pour s'exécuter en réponse à l'interaction. C'est ici que se logent les calculs lourds, les manipulations du DOM mal optimisées ou les appels réseau synchrones.
3. Le délai de présentation (presentation delay) : le temps que met le navigateur à afficher le résultat visuel de l'interaction une fois le code exécuté. Un DOM trop volumineux ou des styles complexes à recalculer allongent cette dernière étape.

Isoler laquelle de ces trois phases domine sur votre site est la première étape avant toute correction : réduire des scripts tiers ne sert à rien si le vrai goulot d'étranglement se situe dans le rendu final de la page.

Comment repérer les Long Tasks qui bloquent votre site ?

Une Long Task est définie de façon précise : toute tâche qui occupe le thread principal du navigateur pendant 50 millisecondes ou plus sans interruption (web.dev, 2026). Ce seuil n'est pas arbitraire : en dessous de 50 millisecondes par tâche, un site peut répondre à une interaction utilisateur en moins de 100 millisecondes au total, ce qui reste imperceptible pour un visiteur.

Deux outils gratuits suffisent pour identifier ces tâches sur votre site :

1. Google PageSpeed Insights (pagespeed.web.dev) : dans la section « Diagnostics », l'outil liste directement les tâches longues détectées lors de l'analyse, avec leur durée et le script JavaScript responsable.
2. Le panneau Performance de Chrome DevTools : en enregistrant une session pendant que vous interagissez avec votre site, les Long Tasks apparaissent visuellement comme des blocs rouges sur la timeline du thread principal, avec le détail de chaque fonction appelée.

En 2025, le Web Almanac de HTTP Archive confirme que ce diagnostic reste nécessaire pour la grande majorité des sites : malgré une amélioration du taux de bon score INP, le temps de blocage total médian sur mobile (Total Blocking Time) a progressé de 58 %, passant de 1 209 à 1 916 millisecondes d'une année sur l'autre (HTTP Archive, 2025). Autrement dit, les sites exécutent globalement plus de JavaScript qu'avant, même quand leur score final s'améliore.

Un point souvent négligé : un score INP qui s'améliore en moyenne ne signifie pas que le JavaScript exécuté a diminué. Il peut simplement être mieux réparti dans le temps, ce qui masque un problème de fond que seul un audit du panneau Performance révèle vraiment.

Comment corriger l'INP sur un site WordPress ou une PME sans refonte ?

La bonne nouvelle : corriger un mauvais INP ne demande presque jamais de reconstruire un site. Quatre leviers concentrent l'essentiel du gain, en particulier sur WordPress où l'accumulation de plugins est la cause la plus fréquente de Long Tasks.

1. Déférencer les scripts non essentiels. Chat en ligne, widgets d'avis clients, pixels publicitaires : chacun ajoute du JavaScript exécuté au chargement, qui peut retarder le délai de saisie de toutes les interactions suivantes. Charger ces scripts après l'interaction initiale de l'utilisateur, plutôt qu'au chargement de la page, réduit directement cette charge. Notre article sur le cache et la vitesse WordPress détaille les leviers complémentaires côté serveur, et notre guide sur le plugin PageSpeed d'o2switch couvre l'optimisation côté hébergement.
2. Optimiser les gestionnaires d'événements JavaScript. Un événement clic qui déclenche une longue chaîne de calculs doit être découpé en tâches plus courtes, par exemple à l'aide de setTimeout(), pour laisser le navigateur respirer entre chaque étape et rester sous le seuil des 50 millisecondes par tâche.
3. Alléger le DOM. Un DOM trop volumineux ralentit directement le délai de présentation, la troisième phase de l'INP. Réduire le nombre d'éléments imbriqués sur les pages les plus riches, en particulier les pages produits ou les pages avec de longs formulaires, accélère le rendu final de chaque interaction.
4. Auditer les plugins WordPress un par un. Sur un site géré sous WordPress, désactiver temporairement chaque plugin et mesurer l'INP avant/après avec PageSpeed Insights permet d'identifier rapidement le ou les responsables, souvent un plugin de formulaire, de popup ou de statistiques mal optimisé.

Chez Le Linter, la majorité des audits menés sur des sites WordPress de PME révèlent le même schéma : deux ou trois plugins concentrent à eux seuls plus de la moitié du temps de blocage total mesuré. Les désactiver ou les remplacer par une alternative plus légère suffit souvent à faire passer l'INP sous la barre des 200 millisecondes.

Ces corrections se mesurent en jours, rarement en semaines, puisqu'elles consistent à retirer ou différer du code existant plutôt qu'à en réécrire. La méthode la plus fiable reste la même que pour les autres Core Web Vitals : mesurer, corriger la cause la plus lourde en premier, puis mesurer à nouveau avant de passer à la suivante.

En résumé

• L'INP mesure la réactivité d'un site à chaque clic, tape ou saisie clavier, pas seulement son temps de chargement initial
• Seuil « bon » : 200 millisecondes ou moins, mesuré au 75e percentile des interactions réelles
• En 2025, seulement 77 % des sites mobiles passent ce seuil, contre 97 % sur desktop
• Une Long Task, tâche qui bloque le navigateur plus de 50 millisecondes, est la cause technique la plus fréquente d'un mauvais INP
• Sur WordPress, deux ou trois plugins concentrent souvent la majorité du temps de blocage : les identifier et les corriger suffit dans la plupart des cas, sans refonte

Vous voulez savoir précisément quels scripts ralentissent la réactivité de votre site ? Parlons-en : un audit technique permet d'identifier les Long Tasks responsables en quelques jours. Si l'INP reste mauvais malgré une chasse aux plugins sérieuse, l'écart de passage constaté entre WordPress et une architecture headless Next.js vaut le détour.