- L’INP mesure la réactivité d’une page : le temps entre un clic, un appui ou une touche et l’affichage qui suit. Il a remplacé le FID dans les Core Web Vitals le 12 mars 2024.
- Seuils Google : ≤ 200 ms bon, 200 à 500 ms à améliorer, > 500 ms mauvais, évalués au 75e centile des visites réelles.
- Chaque interaction se découpe en trois phases : délai d’entrée, traitement, délai de présentation. Corriger l’INP, c’est trouver laquelle déborde.
- La méthode : données de terrain pour trouver les pages et interactions lentes, puis reproduction en laboratoire avec le panneau Performances de Chrome.
- Les remèdes les plus rentables : alléger les scripts tiers, découper les tâches longues (céder la main au navigateur), réduire la taille du DOM.
L’INP (Interaction to Next Paint) est la métrique des Core Web Vitals qui mesure la réactivité d’une page : combien de temps s’écoule entre le moment où l’utilisateur clique, touche l’écran ou appuie sur une touche, et le moment où le navigateur affiche la conséquence visuelle de ce geste. Google considère qu’un INP est bon jusqu’à 200 millisecondes et mauvais au-delà de 500 millisecondes, mesuré sur les visites réelles. Un INP élevé, c’est le bouton « Ajouter au panier » qui semble ne rien faire, le menu mobile qui s’ouvre avec une demi-seconde de retard, le filtre qui fige la page.
Cet article est le guide pratique de la métrique : définition exacte, méthode de diagnostic, exemples de code et corrections par CMS. Pour la vue d’ensemble des trois indicateurs (LCP, INP, CLS) et notre accompagnement, voyez notre page Core Web Vitals.
INP : définition exacte et seuils officiels
La documentation de référence sur web.dev définit l’INP ainsi : pendant toute la visite, le navigateur observe la latence de chaque interaction ; à la fin, la valeur retenue est la plus longue, en ignorant les valeurs aberrantes (une interaction écartée par tranche de 50 sur les pages très interactives). Seules trois familles d’interactions comptent :
- le clic de souris ;
- l’appui sur un écran tactile ;
- l’appui sur une touche du clavier (physique ou virtuel).
Le survol, le défilement et le zoom ne sont pas pris en compte. Une page que l’on se contente de lire sans jamais cliquer n’a donc pas d’INP.
| Valeur INP (75e centile) | Appréciation Google | Ressenti typique |
|---|---|---|
| ≤ 200 ms | Bon | L’interface répond « tout de suite » |
| 201 à 500 ms | À améliorer | Léger flottement, clics parfois répétés |
| > 500 ms | Mauvais | Page qui semble figée, abandon de l’action |
Le 75e centile signifie que, pour être jugée bonne, une page doit offrir un INP de 200 ms ou moins à au moins trois visites sur quatre, séparément sur mobile et sur ordinateur. C’est volontairement exigeant : on juge la page sur ses visiteurs les moins bien lotis (téléphone d’entrée de gamme, processeur occupé), pas sur l’ordinateur du développeur.
Les trois phases d’une interaction
Comprendre ces trois phases est la clé de tout diagnostic, car chacune a des causes et des remèdes différents.
| Phase | Ce qui se passe | Cause typique d’un dépassement | Piste de correction |
|---|---|---|---|
| Délai d’entrée | Le navigateur a reçu le clic mais son fil principal est occupé | Un script (souvent tiers) exécute une tâche longue au même moment | Différer ou alléger les scripts qui tournent pendant la navigation |
| Durée de traitement | Les gestionnaires d’événements (vos fonctions JavaScript) s’exécutent | Trop de travail synchrone dans le clic : calculs, rendu de liste, statistiques | Découper le travail, faire d’abord la mise à jour visuelle |
| Délai de présentation | Le navigateur recalcule styles et mise en page, puis peint | DOM très volumineux, mise en page forcée, gros rendu HTML en JavaScript | Réduire le DOM, éviter les lectures/écritures de mise en page alternées |
Exemple réaliste : un clic sur un filtre « Taille 42 » mesure 640 ms. Le panneau Performances montre 40 ms de délai d’entrée, 520 ms de traitement (le script recalcule et réaffiche 300 produits) et 80 ms de présentation. Le problème est donc dans le traitement : inutile de s’attaquer aux images ou au serveur.
INP ou FID : ce qui a changé en 2024
L’INP a officiellement remplacé le FID le 12 mars 2024, au terme de deux ans de période expérimentale. Le FID a été retiré de la Search Console le même jour.
| FID (retiré) | INP (actuel) | |
|---|---|---|
| Interactions observées | La première uniquement | Toutes les interactions de la visite |
| Ce qui est mesuré | Le seul délai d’entrée | Délai d’entrée + traitement + présentation |
| Seuil « bon » | ≤ 100 ms | ≤ 200 ms |
| Difficulté à obtenir un bon score | Faible : la plupart des sites passaient | Réelle, surtout sur mobile et sites riches en JavaScript |
Conséquence : des sites « au vert » avec le FID sont passés à l’orange ou au rouge avec l’INP sans avoir changé une ligne de code. Ce n’est pas le site qui s’est dégradé, c’est la mesure qui est devenue honnête.
Où mesurer l’INP : terrain et laboratoire
L’INP est avant tout une métrique de terrain : il dépend de ce que font de vrais utilisateurs, sur de vrais appareils. Les outils se répartissent donc en deux familles.
| Outil | Type de données | Ce qu’il vous apprend |
|---|---|---|
| Search Console, rapport Core Web Vitals | Terrain (CrUX), par groupes d’URL | Quels modèles de pages sont lents sur mobile ou ordinateur |
| PageSpeed Insights | Terrain (28 derniers jours) + laboratoire | INP réel d’une URL ou de l’origine, si le trafic est suffisant |
| Bibliothèque web-vitals (RUM maison) | Terrain, vos propres visiteurs | Quelle interaction, sur quel élément, dans quelle phase |
| Chrome DevTools, panneau Performances | Laboratoire | Le détail de chaque tâche pendant une interaction reproduite |
| Lighthouse | Laboratoire | Pas d’INP au chargement, mais le Total Blocking Time, bien corrélé |
PageSpeed Insights affiche les données de terrain du rapport CrUX sur la période des 28 derniers jours. Un site peu visité n’y a souvent aucune donnée : dans ce cas, la seule façon d’obtenir un INP réel est de le collecter vous-même avec la bibliothèque web-vitals de Google, dont la version « attribution » indique l’élément cliqué et la phase fautive :
import {onINP} from 'web-vitals/attribution';
onINP(({value, rating, attribution}) => {
navigator.sendBeacon('/rum', JSON.stringify({
inp: Math.round(value), // en millisecondes
rating, // good | needs-improvement | poor
cible: attribution.interactionTarget, // sélecteur de l'élément
delai: attribution.inputDelay,
traitement: attribution.processingDuration,
presentation: attribution.presentationDelay
}));
});En général, quelques centaines de visites suffisent pour voir apparaître les interactions problématiques. Nos audits et nos corrections techniques s’appuient sur ce type de collecte quand les données publiques manquent.
Méthode de diagnostic pas à pas
La méthode que nous appliquons suit la logique recommandée par Google dans son guide de diagnostic manuel des interactions lentes : trouver sur le terrain, reproduire en laboratoire, corriger, vérifier sur le terrain.
Repérer les modèles de pages lents
Dans la Search Console, rapport Core Web Vitals, repérez les groupes d’URL signalés pour l’INP, en commençant par le mobile. Priorisez selon le trafic et la valeur commerciale (fiches produits, tunnel de commande, formulaires).
Identifier l’interaction fautive
Avec vos données web-vitals ou en testant les éléments interactifs évidents : menu, filtres, ajout au panier, onglets, accordéons, champs de formulaire, bandeau de consentement.
Reproduire dans Chrome
Ouvrez DevTools, onglet Performances, activez un ralentissement du processeur (x4 ou x6) pour simuler un téléphone moyen, lancez l’enregistrement, effectuez l’interaction, arrêtez.
Lire la piste Interactions
Survolez l’interaction : DevTools affiche sa durée et la répartition entre délai d’entrée, traitement et présentation. Les tâches longues sont marquées d’un triangle rouge.
Remonter jusqu’au script
Dépliez la tâche longue pour voir les fonctions appelées et leur fichier d’origine : votre thème, une extension, un script tiers. L’API Long Animation Frames apporte la même attribution sur le terrain.
Corriger une cause à la fois
Appliquez le remède adapté à la phase (voir tableau suivant), puis refaites exactement la même mesure pour comparer.
Valider sur le terrain
Les données CrUX portant sur 28 jours, l’amélioration apparaît progressivement dans PageSpeed Insights et la Search Console. Vos données web-vitals, elles, la montrent dès le lendemain.
Sur le terrain, l’API Long Animation Frames signale les frames de plus de 50 ms et attribue le temps aux scripts responsables (fichier, fonction), ce qui est précieux quand le problème ne se reproduit pas sur votre machine.
Causes fréquentes d’un mauvais INP et remèdes
| Cause | Phase touchée | Comment le repérer | Remède |
|---|---|---|---|
| Scripts tiers (chat, publicité, tests A/B, pixels) | Délai d’entrée | Tâches longues de domaines externes dans DevTools | Supprimer ce qui ne sert plus, charger à l’inactivité ou à la première interaction |
| Gestionnaire de clic monolithique | Traitement | Une seule tâche de plusieurs centaines de ms après le clic | Afficher d’abord le retour visuel, céder la main, puis faire le reste |
| Envoi de statistiques dans le clic | Traitement | Appels de suivi dans la pile de la tâche | Envoyer après la mise à jour visuelle, sans bloquer |
| Réhydratation d’un site JavaScript | Délai d’entrée | Tâches longues au chargement, clics ignorés les premières secondes | Rendu serveur, hydratation partielle ou progressive, moins de composants interactifs |
| DOM très volumineux | Présentation | Recalcul de style et mise en page coûteux après chaque clic | Réduire les éléments, content-visibility sur les zones hors écran, méga-menus chargés à la demande |
| Mise en page forcée en boucle | Traitement / présentation | Avertissement « Forced reflow » dans DevTools | Regrouper les lectures, puis les écritures de styles |
| Champ de recherche qui filtre à chaque frappe | Traitement | Chaque touche déclenche un gros calcul | Temporiser (debounce), filtrer par lots, afficher la saisie immédiatement |
Ces remèdes reprennent les recommandations du guide Google optimiser l’INP. Sur les sites que nous traitons, deux ou trois corrections ciblées suffisent souvent à faire passer un INP mobile à l’orange sous la barre des 200 ms ; il est rare qu’il faille réécrire le site.
Découper les tâches longues : céder la main au navigateur
Une tâche de plus de 50 ms est dite « longue » : pendant ce temps, le navigateur ne peut ni répondre à un nouveau clic ni afficher quoi que ce soit. Le principe de correction est de faire d’abord ce que l’utilisateur doit voir, puis de rendre la main au navigateur pour qu’il peigne, et seulement ensuite de continuer le travail. Google recommande pour cela scheduler.yield(), disponible dans Chrome et Edge depuis la version 129 et dans Firefox depuis la version 142 selon son guide des tâches longues, avec un repli sur setTimeout ailleurs :
function cederLaMain() {
if (globalThis.scheduler?.yield) return scheduler.yield();
return new Promise(r => setTimeout(r, 0)); // repli pour les navigateurs sans scheduler.yield
}
bouton.addEventListener('click', async () => {
afficherChargement(); // 1. retour visuel immédiat
await cederLaMain(); // 2. le navigateur peint la frame
filtrerLesProduits(); // 3. travail lourd ensuite
await cederLaMain();
envoyerStatistiques(); // 4. tâches non urgentes en dernier
});Le même guide précise que l’ancienne API isInputPending() n’est plus recommandée. Ce découpage ne rend pas le calcul plus rapide ; il rend la page réactive pendant le calcul, ce qui est exactement ce que mesure l’INP.
INP selon le CMS : WordPress, Shopify, PrestaShop
WordPress et WooCommerce
Les coupables habituels sont les constructeurs de pages lourds, les extensions qui ajoutent chacune leurs scripts sur toutes les pages, et les sliders. Commencez par un inventaire des scripts chargés sur la page lente, désactivez ce qui ne sert pas sur ce gabarit, et méfiez-vous des réglages « retarder tout le JavaScript » : ils améliorent souvent le LCP mais peuvent faire exploser l’INP de la première interaction. Notre page SEO WordPress détaille notre méthode.
Shopify
Sur Shopify, l’INP se dégrade surtout avec l’accumulation d’applications (avis, upsell, chat, fidélité) qui injectent leurs scripts dans le thème. Un inventaire des applications réellement utiles et le passage à un thème récent et léger règlent la majorité des cas. Voir notre accompagnement SEO Shopify.
PrestaShop
Les modules de navigation à facettes et les méga-menus générant des milliers d’éléments sont les causes les plus fréquentes, ainsi que les anciens thèmes chargeant plusieurs bibliothèques JavaScript. Voir notre page SEO PrestaShop.
Sur une boutique en ligne, l’INP se joue surtout sur les fiches produits, les listes filtrées et le panier : c’est l’un des chantiers de notre offre de SEO pour sites marchands.
L’INP et le classement Google : ce qu’il faut en attendre
Google l’écrit clairement dans sa documentation sur les Core Web Vitals : ces métriques s’inscrivent dans ce que ses systèmes de classement cherchent à récompenser, mais de bons scores ne garantissent pas un bon classement ; un contenu pertinent et utile reste déterminant. Passer de 350 à 180 ms ne fera pas bondir une page médiocre en tête des résultats.
L’enjeu est ailleurs : un mauvais INP fait perdre des conversions sur les pages qui ont déjà du trafic. Un bouton qui ne réagit pas provoque des clics répétés, des doubles ajouts au panier, des formulaires abandonnés. C’est pourquoi nous priorisons l’INP par valeur commerciale, pas par score. Un audit SEO permet de le situer parmi les autres chantiers : il est rarement la priorité absolue d’un site qui manque de contenus ou de liens, mais il le devient sur un e-commerce bien positionné.
Erreurs à éviter
- Se fier au score Lighthouse seul. Il ne mesure pas l’INP au chargement ; un 100/100 peut coexister avec un INP mobile mauvais.
- Tester sur un ordinateur puissant sans ralentissement. Activez le ralentissement du processeur ou testez sur un vrai téléphone Android de milieu de gamme.
- Optimiser les images pour corriger l’INP. C’est le levier du LCP, pas de la réactivité.
- Tout différer aveuglément. Retarder tout le JavaScript jusqu’à la première interaction fait payer l’addition… à la première interaction.
- Oublier le bandeau de consentement. C’est souvent la première interaction de la visite, et certaines solutions sont lourdes.
- Conclure trop vite. Les données CrUX sont glissantes sur 28 jours : attendez quatre semaines avant de juger une correction sur la Search Console.
- Casser les performances lors d’une refonte. Mesurez l’INP en préproduction, comme nous le recommandons dans notre checklist de refonte de site internet SEO.
Pour suivre l’évolution de vos Core Web Vitals dans la Google Search Console, créez une annotation à chaque déploiement correctif : c’est la seule façon de relier une amélioration à une cause. Nous intégrons ces indicateurs à notre reporting SEO mensuel.
Votre site semble lent à réagir sur mobile ? Lancez notre test gratuit ou contactez-nous : nos développeurs identifient l’interaction fautive et la corrigent, pas seulement la signalent.