Votre site charge en 1,8 seconde — bravo pour le LCP. Puis un visiteur tape sur « Ajouter au panier »… et rien ne se passe pendant une demi-seconde. Il retape. Il part. Google, lui, enregistre un INP médiocre. Bienvenue dans la métrique qui remplace le FID depuis 2024 et qui devient, en 2026, l'un des signaux les plus discriminants sur mobile.
Chez Apresta, nous expliquons l'INP (Interaction to Next Paint) à des dirigeants de TPE et PME à Lille et en Hauts-de-France sans passer par un cours de JavaScript. Ce guide fait pareil : définition claire, seuils, causes fréquentes, et actions concrètes pour améliorer la réactivité perçue de votre site.
INP : définition en une phrase
L'INP mesure le délai entre l'action d'un utilisateur (clic, tap, touche) et le moment où le navigateur affiche le prochain visuel de réponse — sur l'ensemble des interactions d'une visite, en retenant la plus lente (pire interaction, hors outliers extrêmes).
Autrement dit : INP répond à « mon site répond-il instantanément quand on interagit ? » — pas seulement « mon site charge-t-il vite ? ». Le LCP mesure le temps de chargement du plus grand élément visible (image hero, titre). L'INP mesure le temps de réponse aux interactions une fois la page affichée. Un site peut afficher un excellent LCP et un INP catastrophique si le JavaScript bloque le thread principal au moindre clic : le visiteur voit la page, mais ne peut pas l'utiliser.
Pourquoi Google a remplacé le FID par l'INP
Le FID (First Input Delay) ne mesurait que la première interaction — souvent le bandeau cookies ou le menu. Un site pouvait afficher un bon FID tout en devenant saccadé dès la deuxième action : filtre catalogue, changement de quantité, validation formulaire.
L'INP corrige cette lacune en observant toutes les interactions significatives pendant la visite, en retenant la valeur la plus défavorable (98e percentile des interactions). Il reflète mieux l'expérience réelle sur un parcours e-commerce ou un formulaire multi-étapes. Depuis mars 2024, INP fait partie officielle des Core Web Vitals. En 2026, les données Search Console et les signaux qualité intègrent ce critère de façon consolidée.
Un LCP vert ne compense pas un INP rouge. Les deux mesurent des problèmes différents — et les deux impactent conversion et SEO.
Les seuils INP à connaître
Google définit trois paliers basés sur les données terrain (CrUX). Un INP bon se situe à 200 ms ou moins. Entre 200 ms et 500 ms, la métrique est à améliorer. Au-delà de 500 ms, elle est mauvaise. Ces seuils s'appliquent au 75e percentile des visites — pas à votre test isolé en Wi-Fi fibre au bureau.
Objectif réaliste pour une PME e-commerce ou vitrine B2B : INP ≤ 200 ms sur mobile pour les templates accueil, catégorie, fiche produit et contact. Si vous n'atteignez ce seuil que sur desktop, vous optimisez pour vous, pas pour vos clients.
Comment mesurer l'INP (sans être développeur)
La distinction la plus importante pour un dirigeant : données terrain versus données lab. Les données terrain proviennent de vrais utilisateurs sur de vrais appareils. Les données lab simulent une visite dans des conditions contrôlées. Pour prioriser un budget, fiez-vous au terrain.
Données terrain — la référence
Google Search Console → Expérience → Core Web Vitals → rapport INP. Ce sont des données réelles agrégées (Chrome User Experience Report). Priorisez ce rapport pour les décisions business : c'est ce que Google voit, et ce que vos visiteurs subissent.
Données lab — le diagnostic
PageSpeed Insights combine données terrain et audit lab. Lighthouse (Chrome DevTools) expose le Total Blocking Time, corrélé aux problèmes INP. La bibliothèque web-vitals, intégrée à Analytics, permet de suivre l'INP par page en production. Le lab sert à comprendre pourquoi ; le terrain sert à décider quoi corriger en premier.
Test manuel simple
Sur smartphone en 4G, ouvrez votre site et tapez immédiatement sur le menu, un filtre ou un accordéon. Si le feedback visuel dépasse ~300 ms ressenti, vous avez probablement un problème INP. Ne testez pas uniquement en Wi-Fi bureau : les utilisateurs lillois en déplacement (Métro, 4G boulevard) subissent des INP pires que vos développeurs en open space.
Ce qui dégrade l'INP : les causes les plus fréquentes
Dans nos audits perf pour des PME en Hauts-de-France, six familles de problèmes reviennent systématiquement. Elles ne sont pas équivalentes en impact : les scripts tiers et le JavaScript bloquant représentent souvent 70 % des cas.
JavaScript lourd sur le thread principal
Chaque clic déclenche parfois des centaines de ms de JS non découpé : recalcul layout, analytics, A/B testing, heatmaps. Le navigateur ne peut pas peindre la réponse tant que le thread est occupé. Sur une fiche produit WooCommerce ou PrestaShop surchargée, un seul handler mal écrit suffit à faire passer l'INP au rouge.
Tiers scripts (chat, pub, tags)
Intercom, HubSpot, Meta Pixel, Hotjar, consent managers mal optimisés — empilés sur chaque page. Un e-commerce avec 15 scripts tiers voit souvent son INP exploser, même si le thème est « optimisé perf ». Le problème n'est pas le thème : c'est la couche marketing ajoutée après coup.
Hydratation React/Vue lente
Les sites headless ou SPA hydratent le HTML côté client. Si l'hydratation bloque 500 ms, le premier tap sur « + » quantité est ignoré ou retardé. C'est un piège fréquent des refontes Next.js mal calibrées : le LCP est vert, l'INP reste orange six mois.
Event handlers et layout mal optimisés
Listeners sur scroll ou mousemove sans debounce, requêtes DOM répétées à chaque clic, re-render complet d'une liste de 200 produits pour un changement de filtre, modifications DOM qui forcent des recalculs layout en cascade — autant de patterns qui dégradent l'INP sans être visibles dans un screenshot.
Main thread bloqué par le consent banner
Le bandeau cookies qui exécute du JS lourd au premier clic « Accepter » compte comme interaction dans l'INP. Beaucoup de sites optimisent le chargement initial, puis oublient que le consent manager bloque le thread au moment où l'utilisateur veut enfin naviguer.
Comment améliorer l'INP : actions par priorité
Sans diagnostic, vous risquez de supprimer le mauvais script. Commencez toujours par identifier le coupable, puis traitez par ordre d'impact.
Priorité 1 — Identifier le coupable. Chrome DevTools → Performance → enregistrez une session avec clic. Repérez les « Long Tasks » supérieures à 50 ms. C'est votre liste de travail concrète, pas une intuition.
Priorité 2 — Réduire le JavaScript. Différez (defer, dynamic import) tout script non critique. Supprimez plugins et modules inutilisés sur WordPress ou PrestaShop. Code-splittez par route si vous êtes sur Next.js ou Nuxt. Remplacez du jQuery legacy par du vanilla JS quand c'est pertinent — chaque kiloote de JS inutile retarde chaque interaction.
Priorité 3 — Optimiser les interactions clés. Feedback visuel immédiat sur les boutons (état loading) même si le traitement continue. Debounce des filtres à 300 ms au lieu de recalcul instantané. Virtualisation des longues listes : afficher 20 items, pas 200 nœuds DOM. requestAnimationFrame pour les mises à jour visuelles.
Priorité 4 — Tiers scripts sous contrôle. Chargez le chat après 5 s ou après scroll. Configurez le tag manager avec des déclencheurs stricts — pas « all pages all events ». Activez l'auto-blocking consent (Axeptio mode perf, par exemple) avant le chargement des pixels.
Priorité 5 — Server-side rendering. Pour les stacks modernes : SSR ou SSG pour le HTML initial, hydratation progressive (Partial Hydration, Islands Architecture). Le contenu interactif critique doit répondre sans attendre l'hydratation complète.
Pour le contexte global CWV : Core Web Vitals 2026 — LCP, INP, CLS. Pour une introduction plus large : Core Web Vitals — guide non-techniciens.
INP et e-commerce : interactions qui comptent le plus
Sur une boutique en ligne, l'INP se joue sur un nombre limité d'interactions répétées : tap « Ajouter au panier », changement de quantité, ouverture des filtres, sélection de variantes, validation des étapes checkout, ouverture du mini-cart. Si l'une de ces interactions dépasse 500 ms sur mobile, vous perdez des ventes — pas seulement un indicateur Search Console.
Cas anonymisé (PME e-commerce HDF, 2025) : INP passé de 420 ms à 165 ms après suppression de 4 scripts tiers et debounce des filtres. Taux d'ajout panier mobile : +18 % en 6 semaines. Corrélation, pas garantie — mais le lien UX / CA est documenté sur des dizaines de projets similaires.
INP vs TBT vs FID : ne pas confondre les métriques
Le FID est obsolète : il ne mesurait que la première interaction. Le TBT (Total Blocking Time) est une métrique lab Lighthouse, somme des long tasks — un proxy utile pour diagnostiquer l'INP en développement. L'INP est une métrique terrain CrUX qui observe toutes les interactions et retient le pire cas.
Un bon TBT en lab ne garantit pas un bon INP terrain (appareils lents, réseau 3G). Inversement, un TBT élevé en lab signale presque toujours un INP à risque en production. Ne confondez pas les deux lors d'une réunion de pilotage.
Objectif Lighthouse 90+ et INP
Beaucoup de dirigeants visent un score Lighthouse supérieur à 90. C'est un outil lab, pas un facteur de ranking direct. TBT et INP lab y contribuent — mais le score global peut masquer un INP terrain médiocre si le test est fait en conditions optimales.
Notre approche : viser CWV « bon » en terrain Search Console plutôt qu'un chiffre Lighthouse isolé. Voir : Lighthouse 90+ — comment l'atteindre.
Plan d'action INP en 4 semaines (PME)
Semaine 1 — Baseline. Exportez l'INP Search Console par URL. Lancez PageSpeed Insights mobile sur vos 5 pages les plus visitées. Inventoriez les scripts tiers via Chrome DevTools → Network, extensions désactivées.
Semaine 2 — Quick wins. Différez analytics et chat. Ajoutez un feedback visuel immédiat sur les CTA principaux. Supprimez les scripts morts identifiés à la semaine 1.
Semaine 3 — Optimisation dev. Corrigez les long tasks identifiées en Performance profile. Debouncez filtres et recherche. Revoyez l'hydratation si vous êtes sur une SPA ou un site headless.
Semaine 4 — Validation. Retestez Search Console (délai 28 jours pour données CrUX mises à jour). Testez en 4G smartphone sur le parcours complet. Documentez un budget JS max pour les futures features.
Coût typique intervention INP ciblée : 1 500 € à 5 000 € HT selon stack et dette JavaScript — souvent inclus dans une refonte perf globale.
FAQ
INP est-il un facteur de ranking direct ?
Google confirme que les Core Web Vitals (dont INP) sont un signal de ranking, mais pas le seul. L'impact est modéré comparé au contenu et aux backlinks — mais un INP > 500 ms nuit clairement à l'expérience et à la conversion, ce qui indirectement affecte vos résultats business.
Pourquoi mon INP est rouge alors que Lighthouse affiche 95 ?
Lighthouse teste en lab, souvent desktop ou mobile simulé avec connexion rapide. INP Search Console agrège des vrais utilisateurs sur appareils entrée/milieu de gamme, en mobilité. L'écart est normal — fiez-vous au terrain pour prioriser.
Puis-je améliorer l'INP sans refonte complète ?
Oui, dans la majorité des cas. Suppression/différé de scripts tiers et optimisation des handlers représentent souvent 60–70 % du gain. Une refonte complète n'est nécessaire que si le thème ou le framework est structurellement inadapté (SPA lourde mal architecturée).
L'INP concerne-t-il les sites vitrine ou seulement l'e-commerce ?
Tous les sites avec interactions : menus, formulaires, accordéons FAQ, sliders, simulateurs de devis. Un site vitrine B2B avec un formulaire contact lent souffre autant qu'une fiche produit e-commerce.
Combien de temps avant de voir l'INP s'améliorer dans Search Console ?
Les données CrUX se mettent à jour sur un cycle de 28 jours glissants. Comptez 4 à 8 semaines après déploiement pour voir le rapport Search Console refléter les corrections — mesurez en lab immédiatement pour valider le fix.
Et maintenant ?
L'INP traduit une question simple que vos utilisateurs se posent : « est-ce que ce site répond quand je clique ? » Si vos Core Web Vitals mobile affichent un INP orange ou rouge, nous pouvons profiler votre site, identifier les long tasks responsables et vous proposer un plan de correction adapté à votre stack — WooCommerce, Shopify, PrestaShop ou sur mesure.