INP : la nouvelle Core Web Vital qui peut faire chuter votre SEO

Si vous avez regardé vos rapports Search Console ces six derniers mois et constaté un volume croissant de pages signalées en « à améliorer » ou « médiocre » sur les Signaux Web essentiels, sans que votre site ait fondamentalement changé, vous avez probablement croisé l’effet INP. L’Interaction to Next Paint a remplacé le FID (First Input Delay) comme Core Web Vital officiel en mars 2024. Pendant les six premiers mois, l’impact a été limité — beaucoup de sites passaient le seuil par défaut. En 2026, la situation s’est nettement durcie. Sur les audits que nous menons chez Bluewave, l’INP est devenu le Core Web Vital qui place le plus de sites en zone rouge, devant le LCP et largement devant le CLS. Cet article explique pourquoi cette métrique est devenue critique, comment la diagnostiquer correctement, et quels leviers techniques produisent des gains tangibles en quelques semaines.

Un rappel rapide pour ceux qui découvrent le sujet. Les Core Web Vitals sont les trois métriques de performance que Google utilise comme signal de classement direct. LCP pour la vitesse perçue du chargement (apparition du plus gros élément visible), INP pour la réactivité aux interactions utilisateur, CLS pour la stabilité visuelle (éléments qui se déplacent pendant le chargement). Pour le contexte e-commerce et l’impact business, nous avons publié un guide complet dans la série Marques. Cet article se concentre exclusivement sur l’INP — parce que c’est aujourd’hui le sujet qui mérite une attention prioritaire, et parce que c’est le moins bien compris des trois.

Qu’est-ce que l’INP, vraiment

L’INP mesure le délai entre une interaction utilisateur (clic, tap, saisie clavier) et la prochaine peinture de l’écran qui en résulte. C’est volontairement une définition simple : combien de temps s’écoule entre le moment où vous touchez le bouton « Ajouter au panier » et le moment où l’interface vous montre que quelque chose s’est passé. Si ce délai dépasse 200 ms, l’utilisateur perçoit une lenteur. S’il dépasse 500 ms, l’utilisateur perçoit un dysfonctionnement.

La différence fondamentale avec l’ancien FID est subtile mais critique. Le FID ne mesurait que la première interaction sur une page, et seulement le délai avant que le navigateur commence à traiter cette interaction (pas avant que l’écran soit mis à jour). L’INP mesure toutes les interactions sur la page, prend la plus lente (au-delà d’un seuil de 50 ms), et la considère sur l’ensemble du cycle interaction → peinture. C’est plus représentatif de l’expérience réelle, mais c’est aussi beaucoup plus exigeant — un site peut avoir un excellent FID et un INP catastrophique.

Google mesure l’INP à partir de deux sources combinées. La première est le CrUX (Chrome User Experience Report), qui agrège les données des utilisateurs Chrome réels qui ont activé la collecte. Sur un site avec suffisamment de trafic (plus de 5 000 visites/mois environ), cette donnée est disponible et utilisée pour le classement. La seconde, depuis 2025, est la possibilité d’envoyer ses propres mesures terrain via le système de Real User Monitoring (RUM) — Google encourage les sites à instrumenter leur trafic pour fournir des données plus précises, particulièrement utile pour les sites à faible trafic où CrUX est lacunaire.

Les seuils officiels et ce qu’ils signifient en SEO

Les seuils INP sont publiés par Google et stables depuis l’introduction de la métrique. Trois zones, et la zone qui compte pour le classement Google est celle du 75e percentile des visiteurs sur 28 jours glissants.

Zone	Seuil INP	Perception utilisateur	Impact SEO
Bon (vert)	≤ 200 ms	Réponse perçue comme instantanée	Signal positif
À améliorer (orange)	200-500 ms	Lenteur perçue, friction subtile	Pas de pénalité directe, mais désavantage face à concurrent en vert
Médiocre (rouge)	> 500 ms	Site perçu comme dysfonctionnel	Pénalité de classement explicite

L’impact SEO de l’INP est plus indirect que celui du LCP, mais il existe. Google a confirmé en plusieurs occasions que les Core Web Vitals sont un signal de classement à part entière, pas seulement un facteur de tie-breaking. Concrètement, sur une requête concurrentielle où trois sites se disputent les positions 1 à 5, le site qui est en zone verte sur l’INP a un avantage mesurable sur celui qui est en orange, et un avantage net sur celui qui est en rouge. Sur les marques DTC premium que nous accompagnons, nous mesurons en moyenne 1 à 4 positions de différence sur les requêtes commerciales concurrentielles entre une fiche produit en zone verte INP et une fiche produit équivalente en zone rouge, à contenu et autorité égaux.

Au-delà du classement, l’INP impacte le comportement utilisateur de manière directe. Sur les sites où nous avons mesuré l’évolution avant/après un chantier INP, le taux de conversion augmente typiquement de 8 à 18 % en valeur relative quand on passe d’une zone orange (entre 300 et 500 ms) à une zone verte (en dessous de 200 ms). Sur une boutique qui réalise 300 commandes par mois avec un panier moyen de 90 €, c’est entre 2 200 et 4 800 € de CA additionnel par mois — pour un chantier qui prend typiquement 2 à 5 semaines.

Pourquoi tant de sites e-commerce et hôteliers sont en zone rouge

Les sites e-commerce et hôteliers cumulent des facteurs qui dégradent mécaniquement l’INP. Quatre causes principales, observées de manière récurrente sur les audits.

Première cause : la surcharge JavaScript. Sur les boutiques que nous auditons, on trouve typiquement 800 ko à 2,4 Mo de JavaScript total téléchargé sur la première page produit. Les responsables : le framework du thème (jQuery, Vue, React selon les stacks), les scripts de tracking (Google Tag Manager qui empile typiquement 15 à 30 tags), les scripts marketing (Klaviyo, Mailchimp, Brevo, popups d’engagement), les scripts d’avis (Trustpilot, Avis Vérifiés, Yotpo), les scripts de chat (Crisp, Intercom, Tidio), et les scripts de personnalisation (Nosto, Klaviyo Personalization, AB Tasty). Chaque interaction utilisateur déclenche un cycle de traitement JavaScript qui doit attendre que la thread principale soit libre — sur un téléphone milieu de gamme en 4G partielle, c’est là que les 500 ms se construisent.

Deuxième cause : les third parties. Au-delà du volume de JavaScript propre au site, les scripts tiers chargés depuis des domaines externes sont souvent les plus pénalisants. D’abord parce qu’ils s’exécutent souvent en synchrone (bloquent le thread principal), ensuite parce qu’ils sont fréquemment chargés avec une priorité incorrecte par le navigateur, enfin parce que leurs propres dépendances génèrent des cascades imprévisibles. Sur un site hôtelier 5★ récemment audité, nous avons identifié 38 scripts tiers actifs au chargement de la home — chacun ajoutant entre 5 et 80 ms de latence sur la première interaction utilisateur.

Troisième cause : les widgets de réservation et de panier. Sur les sites hôteliers, le widget de réservation (Cubilis, SiteMinder, D-Edge, ou widget custom) est très souvent l’élément qui plombe l’INP de la page de présentation des chambres — interaction « ouvrir le widget de disponibilité » qui prend 600 à 1 200 ms parce que le widget initialise lourdement au moment du clic. Sur les sites e-commerce, l’interaction « ajouter au panier » ou « ouvrir la mini-cart » est l’équivalent — initialisations multiples, requêtes AJAX synchrones, mise à jour DOM lourde.

Quatrième cause : les frameworks rendus côté client trop lourds. Sur les sites construits sur React, Vue ou Angular sans optimisation (hydration complète, pas de code splitting, pas de lazy hydration), le navigateur doit traiter une grande quantité de JavaScript avant que la moindre interaction soit réactive. C’est un problème particulièrement visible sur les sites construits entre 2020 et 2023, quand les architectures « SPA » étaient encore dominantes — la mode du SSR et de l’hydration partielle est arrivée plus tard.

L’INP est la métrique qui révèle l’accumulation silencieuse de dette technique sur le frontend. Un site qui ajoute un script tiers par trimestre pendant cinq ans, sans jamais en retirer, finit mathématiquement en zone rouge — même si chaque ajout pris isolément paraissait inoffensif.

Diagnostiquer correctement : les outils dans le bon ordre

Diagnostiquer l’INP correctement est plus subtil que mesurer le LCP. Quatre outils, à utiliser dans un ordre précis pour obtenir un diagnostic actionnable.

PageSpeed Insights : la photo, pas le diagnostic

PageSpeed Insights (pagespeed.web.dev) est l’entrée évidente. Il faut savoir lire deux blocs distincts. Le bloc « Données de l’expérience utilisateur réelle » utilise CrUX sur 28 jours — c’est cette valeur qui compte pour Google. Le bloc « Diagnostic » est une simulation laboratoire — utile pour vérifier l’effet d’un correctif rapidement, mais sans valeur SEO directe. Sur les sites à faible trafic (moins de 5 000 visites/mois), la donnée CrUX peut être absente : c’est un piège, car le score laboratoire affiché peut être vert alors que les visiteurs réels subissent une zone rouge.

Search Console : la vérité terrain agrégée

Le rapport « Signaux Web essentiels » de Search Console est l’outil le plus important sur la durée. Il classe vos pages indexées en trois zones (bon, à améliorer, médiocre) sur mobile et desktop, à partir des données CrUX. C’est sur ce rapport que Google se base pour son classement. La vérification d’un correctif n’est validée que quand le rapport Search Console le reflète — typiquement 28 à 35 jours après le déploiement. Aucun changement ne devrait être considéré comme acquis tant qu’il n’apparaît pas dans ce rapport.

Chrome DevTools : la séquence d’événements précise

Pour identifier quelle interaction pose problème, Chrome DevTools est l’outil de référence. L’onglet Performance permet d’enregistrer une session de navigation et de visualiser la timeline des interactions, avec pour chacune le délai mesuré. La fonction « Web Vitals » dans DevTools (à activer dans les Experiments depuis Chrome 121) surligne directement les interactions au-delà de 200 ms et identifie le long task responsable. Sur une boutique e-commerce, c’est typiquement comme ça qu’on découvre que l’interaction « ouvrir mini-cart » prend 720 ms parce qu’elle déclenche une initialisation Klaviyo synchrone.

Real User Monitoring : l’instrument à mettre en place

Pour les sites suffisamment sérieux pour traiter le sujet sur la durée, un RUM dédié (SpeedCurve, Vercel Analytics, Cloudflare Web Analytics avec RUM, ou web-vitals.js custom envoyé vers votre propre endpoint) capture les mesures terrain de chaque visiteur en temps réel. C’est ce qui permet de détecter une régression INP dans les heures suivant un déploiement, plutôt que dans les 28 jours suivants quand le CrUX agrégé l’aura confirmé. Sur les boutiques DTC dont l’équipe fait des releases hebdomadaires, le RUM est en pratique indispensable.

Les leviers de correction par effet décroissant

Sur les chantiers INP que nous menons, six leviers couvrent l’essentiel des gains. Ils sont listés ici par ordre d’impact décroissant — commencez toujours par le levier 1, ne passez au levier suivant que lorsque le précédent est traité.

Levier 1 — Suppression et différement des scripts tiers non critiques. C’est de loin le levier le plus rentable. Un audit sérieux des scripts tiers actifs sur la première interaction identifie typiquement 5 à 15 scripts qui peuvent être supprimés sans perte fonctionnelle (outils abandonnés, doublons, modules de test toujours actifs), et 60 à 80 % des scripts restants qui peuvent être chargés en différé (defer, ou via Intersection Observer après la première interaction). Gain typique : 150 à 400 ms d’INP, sans aucun travail sur le code applicatif.

Levier 2 — Debouncing et throttling des handlers JavaScript. Beaucoup d’interactions sont attachées à des handlers JavaScript qui s’exécutent à chaque événement (input, scroll, resize), saturant le thread principal. Le debouncing (regrouper les événements proches) ou le throttling (limiter la fréquence d’exécution) réduisent drastiquement la charge — gain typique 50 à 200 ms sur les interactions de saisie et de défilement.

Levier 3 — Code splitting et lazy hydration. Sur les sites construits avec un framework JS, le code splitting permet de ne charger initialement que ce qui est nécessaire au premier rendu, et de différer le reste à la demande. La lazy hydration (Vue 3, React Server Components, Astro Islands) ne « réveille » l’interactivité que des composants visibles ou en cours d’interaction. Gain typique : 100 à 300 ms sur les pages chargées de composants interactifs.

Levier 4 — Web Workers pour les calculs lourds. Si votre site fait des calculs côté client (recommandation produits, recherche avancée, configurateur produit, simulateur de prix), ces calculs doivent tourner dans un Web Worker, pas dans le thread principal. C’est moins évident techniquement, mais ça libère le thread principal pour les interactions utilisateur. Gain typique : 100 à 400 ms sur les interactions lourdes.

Levier 5 — Optimisation des handlers de panier et widget critiques. Sur les interactions stratégiques (ajout panier, ouverture mini-cart, widget de réservation hôtelier), une revue ciblée du code identifie souvent des opérations inutilement coûteuses : requêtes AJAX synchrones, manipulations DOM massives, recalculs CSS forcés. Gain typique 200 à 500 ms sur ces interactions précises.

Levier 6 — content-visibility et will-change CSS. Pour les sections de page hors écran, l’attribut CSS content-visibility: auto évite que le navigateur calcule le layout des éléments invisibles à chaque interaction. Pour les éléments qui vont être animés, will-change indique au navigateur de préparer une couche GPU. Gains plus modestes (20 à 80 ms), mais cumulatifs.

Cas concret e-commerce : ajout au panier de 800 ms à 150 ms

Voici un cas que nous avons traité au premier semestre 2026 sur une marque DTC cosmétique. Constat de départ : l’interaction « ajouter au panier » mesurée à 820 ms en INP médian, avec des pics au-delà de 1 200 ms sur certains mobiles. La page produit recevait 35 000 visites mensuelles, dont 78 % sur mobile. Le taux de conversion se situait à 1,9 % — correct pour le secteur, mais avec une marge perceptible.

L’analyse Chrome DevTools a identifié trois causes principales. D’abord, l’ajout au panier déclenchait une requête AJAX synchrone vers le serveur, qui mettait 300 ms en moyenne. Ensuite, le retour de cette requête déclenchait l’initialisation complète de la mini-cart, y compris le chargement des produits associés (3 produits supplémentaires fetchés), qui prenait 280 ms supplémentaires. Enfin, l’événement de tracking Klaviyo « add_to_cart » s’exécutait en synchrone, ajoutant 180 ms.

Le chantier de correction a été mené sur 12 jours de développement, étalés sur 3 semaines pour intégrer le recettage. Trois actions principales. Première action : rendre l’ajout au panier optimiste — l’interface est mise à jour immédiatement avec une confirmation visuelle, la requête serveur tourne en arrière-plan, l’état est réconcilié au retour avec un rollback en cas d’erreur. Deuxième action : chargement différé des produits associés de la mini-cart — ils n’apparaissent qu’à l’ouverture de la mini-cart, pas à l’ajout au panier. Troisième action : passage de l’événement Klaviyo en chargement asynchrone via Tag Manager server-side, sortant complètement du chemin critique de l’interaction.

Mesure	Avant chantier	Après chantier (T+28 jours CrUX)	Gain
INP médian « ajout au panier »	820 ms	150 ms	−670 ms (−82 %)
INP 75e percentile (mesure SEO)	1 080 ms	240 ms	−840 ms (−78 %)
Zone Search Console (mobile)	Médiocre	Bon	−2 zones
Taux de conversion mobile	1,9 %	2,3 %	+21 %
Position moyenne SERP (top 10 produits)	8,4	6,1	+2,3 positions

Ce qui rend ce cas pédagogique n’est pas la magnitude du gain isolément, c’est le ratio. 12 jours de développement, environ 8 000 € de coût technique, +21 % de taux de conversion mobile, soit environ 2 800 € de CA additionnel par mois en régime de croisière. ROI inférieur à 3 mois, et bénéfices durables sur le SEO produit. C’est exactement le profil de chantier que nous recommandons sur les marques DTC qui ont atteint un plateau de croissance et cherchent des leviers d’optimisation sans dépenser en acquisition.

Cas concret hôtelier : widget de réservation qui bloque l’interaction

Deuxième cas concret, sur un hôtel 5★ en région PACA en début 2026. Symptôme : le widget de réservation, intégré sur la page d’accueil et sur la page « Réserver », mettait 1 350 ms en INP au 75e percentile mobile sur l’interaction « sélectionner les dates ». La direction commerciale constatait un taux d’abandon élevé sur le tunnel de réservation, sans en identifier la cause précise.

L’analyse a révélé un pattern fréquent en hospitality : le widget de réservation (intégré via JavaScript fourni par le channel manager) s’initialisait lourdement au moment du clic, parce que toutes les disponibilités étaient pré-chargées en synchrone à l’ouverture du calendrier. Sur un téléphone milieu de gamme en réseau dégradé, cette initialisation prenait fréquemment plus d’une seconde.

La correction a impliqué deux interventions. D’abord, isolement du widget de réservation dans un iframe dédié — geste contre-intuitif (un iframe ajoute une couche), mais qui isole complètement l’exécution JavaScript du widget de celle du thread principal de la page, en faisant un thread autonome dans le navigateur. Ensuite, pré-chargement intelligent du widget : un Intersection Observer détecte quand la zone du widget approche de la viewport et déclenche le préchargement asynchrone du widget — au moment où l’utilisateur clique, le widget est déjà chargé en arrière-plan.

Résultat : INP de l’interaction « sélectionner les dates » passé de 1 350 ms à 220 ms en mesure CrUX terrain, soit dans la zone « à améliorer » mais à la limite du « bon ». Le taux de complétion du tunnel de réservation (du clic « réserver » à la confirmation) a progressé de 14 % en valeur relative sur les 60 jours suivants. Le chantier a mobilisé 7 jours de développement.

Ce que Bluewave monitor systématiquement et dans quel ordre on intervient

Sur les marques DTC et les hôtels que nous accompagnons en monitoring continu, voici la grille INP que nous appliquons. Elle n’est pas exhaustive, mais elle couvre les 90 % de cas qui produisent les pénalités SEO.

Monitoring continu en RUM : INP au 75e percentile sur 7 jours glissants, par type de page (home, fiche produit/chambre, panier/tunnel, recherche), par device (mobile, desktop), par pays/région principale. Toute dégradation supérieure à 50 ms ou tout passage de zone (vert → orange, orange → rouge) déclenche une alerte.

Suivi Search Console hebdomadaire : évolution du nombre de pages en zone rouge, médiocre et bonne. Identification des groupes d’URL qui se dégradent (souvent un type de page entier, pas une page isolée).

Audit trimestriel des scripts tiers : inventaire complet, tri par effort/impact, suppression des scripts abandonnés. Sur les sites mal tenus, on retire 3 à 8 scripts tiers par trimestre, ce qui maintient la stack sous contrôle.

Ordre d’intervention : 1) supprimer les scripts inutiles, 2) différer les scripts non critiques, 3) optimiser les interactions stratégiques (panier, widget réservation), 4) traiter la dette frontend résiduelle (handlers JS lourds, calculs synchrones). Cet ordre est important : commencer par optimiser le code applicatif avant d’avoir nettoyé les scripts tiers est très souvent une perte de temps.

Sur l’INP, le bon chantier n’est pas le plus technique — c’est celui qui commence par retirer ce qui ne sert pas avant d’optimiser ce qui sert. Sur 80 % des audits que nous menons, le simple nettoyage des scripts tiers règle la majorité du problème.

Verdict Bluewave : la métrique à prioriser en 2026

Notre verdict est sans ambiguïté. Sur les Core Web Vitals en 2026, l’INP est la métrique qui mérite l’attention prioritaire. Pour trois raisons. Premièrement, c’est elle qui pénalise le plus de sites — sur les audits que nous menons, environ 55 à 65 % des sites e-commerce et hôteliers premium audités sont en zone orange ou rouge sur l’INP, contre 25 à 35 % sur le LCP et moins de 10 % sur le CLS. Deuxièmement, c’est la plus subtile à diagnostiquer — elle révèle des problèmes que les autres métriques ne montrent pas, particulièrement la surcharge JavaScript progressive. Troisièmement, c’est celle dont les leviers de correction sont les plus rentables — un audit + chantier INP de 2 à 5 semaines produit des gains business mesurables en 30 à 90 jours.

Pour une direction technique ou un directeur e-commerce qui hérite d’un site dont les performances se dégradent lentement, le bon réflexe en 2026 est de commencer par un audit INP ciblé — pas un audit global de performance. L’audit INP identifie en 2 à 3 jours les interactions stratégiques en zone rouge, cartographie les scripts tiers responsables, et chiffre le plan de correction. C’est l’investissement de quelques jours qui débloque ensuite des semaines de chantier ciblé avec un ROI prévisible.

Pour les directions qui voient leur trafic SEO produit se dégrader sans cause identifiée, l’INP est très souvent la cause cachée. Pour les marques DTC qui plafonnent en taux de conversion mobile, l’INP est très souvent le frein invisible. Pour les hôtels 4-5★ dont le taux de complétion du booking direct stagne, l’INP du widget de réservation est très souvent la friction non identifiée. Dans ces trois cas, la grille de diagnostic présentée dans cet article est applicable immédiatement.

Pour aller plus loin sur les Core Web Vitals dans leur ensemble (LCP, INP, CLS combinés, impact SEO et conversion), nous avons publié un guide complet dans la série Marques. Pour les directions hôtelières qui veulent comprendre comment WordPress 7 améliore mécaniquement l’INP via la nouvelle Interactivity API, l’article dédié de cette série Veille en détaille les mécaniques. Et pour les marques DTC qui se demandent si une migration Prestashop 9 résoudrait leurs problèmes de performance, l’article correspondant de la série Veille apporte un cadrage stratégique.

Auditer l’INP de votre site en 2 à 3 jours ? Nos consultants techniques mènent un audit INP ciblé qui identifie les interactions en zone rouge, cartographie les causes (scripts tiers, code applicatif, frameworks), et chiffre un plan d’action priorisé avec ROI estimé. Demander un audit technique Bluewave ou échanger avec un expert performance.