INP : diagnostiquer les interactions lentes côté SEO

L’Interaction to Next Paint (INP) mesure la réactivité perçue d’une page lorsqu’un visiteur clique, touche un élément ou saisit du texte. Pour un site éditorial, e-commerce ou SaaS, une interaction lente peut compromettre une action importante : ouvrir un menu, ajouter un produit au panier, choisir une variante, filtrer une liste, lancer une recherche ou envoyer un formulaire.

Le sujet ne se résume pas à un score de performance. L’INP fait partie des Core Web Vitals suivis par Google. Il reflète surtout un problème concret d’expérience utilisateur : le navigateur reçoit une action, mais tarde à afficher le résultat attendu. Lorsque ce délai survient sur des pages qui attirent du trafic organique, il peut réduire la qualité du parcours après le clic depuis les résultats de recherche.

Le bon diagnostic ne consiste donc pas à lancer un seul audit Lighthouse et à réduire quelques fichiers JavaScript au hasard. Il faut relier les interactions réellement lentes aux pages, appareils, composants front-end, scripts tiers et parcours qui comptent. Cette méthode donne un cadre pour y parvenir, de la donnée terrain à la validation des correctifs.

Pourquoi l’INP reste un indicateur à surveiller en 2026

Google a remplacé le First Input Delay (FID) par l’INP dans les Core Web Vitals en mars 2024. La différence est importante. Le FID évaluait uniquement le délai avant le début du traitement de la première interaction. L’INP s’intéresse à la réactivité globale des interactions pendant la visite et tient compte du délai avant traitement, du traitement lui-même et du délai avant le prochain affichage visible.

Autrement dit, une page peut répondre correctement au premier clic tout en restant difficile à utiliser ensuite. Un menu peut être rapide, mais un filtre de catalogue, une sélection de taille ou le bouton d’ajout au panier peut déclencher beaucoup de JavaScript et se révéler lent. L’INP est conçu pour mieux refléter ce type de situation.

Les seuils communiqués par Google permettent de situer une page ou une origine :

• 200 ms ou moins : bonne réactivité ;
• plus de 200 ms et jusqu’à 500 ms : amélioration nécessaire ;
• plus de 500 ms : réactivité insuffisante.

Ces valeurs se lisent au 75e percentile : l’objectif n’est pas de regarder seulement le cas le plus rapide ou une moyenne flatteuse. Une proportion non négligeable de visites lentes suffit à dégrader la distribution. C’est notamment fréquent sur mobile, où la puissance de calcul, les conditions réseau et la concurrence entre scripts produisent des résultats plus hétérogènes.

Du point de vue SEO, l’INP n’explique pas à lui seul la visibilité d’une URL. Google rappelle que les signaux d’expérience de page font partie d’un ensemble plus large. La pertinence du contenu, l’indexabilité, l’architecture interne et les liens restent déterminants. En revanche, ignorer une mauvaise réactivité sur des pages de destination organiques reviendrait à négliger une friction visible pour les utilisateurs et mesurable dans les données terrain.

L’INP doit donc être intégré à une démarche plus large. Il complète le LCP, qui concerne l’affichage du contenu principal, et le CLS, qui mesure la stabilité visuelle. Pour mieux cadrer ces sujets, consultez aussi notre guide sur les effets réels des Core Web Vitals sur le SEO.

Comprendre ce que mesure réellement une interaction lente

Une interaction ne se limite pas à l’exécution d’une fonction JavaScript. Son délai comprend plusieurs phases que l’on doit distinguer pour corriger la bonne cause :

• Le délai d’entrée : l’utilisateur a cliqué ou touché l’écran, mais le thread principal est déjà occupé. L’événement attend son tour.
• Le temps de traitement : les écouteurs d’événements, calculs JavaScript, modifications du DOM ou appels synchrones s’exécutent.
• Le délai de présentation : le traitement est terminé, mais le navigateur doit encore calculer les styles, réaliser la mise en page, peindre l’interface et l’afficher.

Cette décomposition évite des conclusions simplistes. Un bouton peut être lent parce qu’un tag analytique monopolise le thread principal au même moment. Il peut aussi être lent parce que son gestionnaire d’événement reconstruit une grande partie du DOM, ou parce qu’un changement de classe déclenche un recalcul de styles coûteux sur une liste de plusieurs centaines d’éléments.

Les longues tâches constituent un signal de diagnostic utile. Dans Chrome, une tâche exécutée plus de 50 ms sur le thread principal est considérée comme une longue tâche. Pendant son exécution, le navigateur ne peut généralement pas répondre rapidement à une nouvelle interaction. Une succession de longues tâches après le chargement initial est particulièrement problématique : la page semble prête, mais reste indisponible dès que l’utilisateur commence à agir.

Certains composants méritent une attention prioritaire sur les pages SEO :

• menus mobiles et mégamenus ;
• recherche interne, autocomplétion et suggestions ;
• filtres à facettes, tris et chargement de résultats ;
• galeries produit, choix de variantes et boutons de panier ;
• formulaires de génération de leads ;
• bannières de consentement et gestionnaires de préférences ;
• lecteurs vidéo, cartes interactives, chats et widgets sociaux.

Les filtres méritent un traitement particulier dans un contexte e-commerce. Ils peuvent créer à la fois un problème de réactivité et une multiplication d’URL peu utiles au crawl. Les deux chantiers sont liés sans être identiques : notre article sur le SEO des facettes et le gaspillage de crawl traite du second aspect.

Distinguer CrUX, Search Console, RUM et tests de laboratoire

Une analyse fiable commence par la compréhension des sources de données. Elles ne répondent pas toutes à la même question et ne doivent pas être mises en concurrence.

CrUX et Search Console : la vision agrégée des visiteurs Chrome

Le Chrome UX Report, ou CrUX, rassemble des données d’expérience utilisateur collectées auprès d’utilisateurs réels de Chrome ayant accepté la synchronisation et le partage de statistiques d’utilisation. Les données sont agrégées et reposent sur une fenêtre glissante de 28 jours. Elles sont accessibles notamment via PageSpeed Insights, l’API CrUX et le rapport Core Web Vitals de Google Search Console.

Dans Search Console, le rapport Core Web Vitals regroupe les URL présentant des problèmes similaires. Il est utile pour repérer une famille de pages affectée, suivre une tendance et demander une validation après correction. Il ne fournit toutefois pas le détail d’un clic précis, le nom d’un composant React, Vue ou Angular, ni la chaîne complète des scripts exécutés lors de l’interaction.

Il faut également garder en tête que toutes les URL ne disposent pas forcément d’assez de données terrain publiées. Dans ce cas, une vision au niveau de l’origine peut être disponible alors que la vision par URL ne l’est pas. Cela ne permet pas de conclure que chaque modèle de page a le même comportement : une origine mélange parfois des pages très différentes.

Le RUM : la donnée qui relie une latence à un parcours

Le Real User Monitoring (RUM) mesure les performances sur votre propre audience. C’est la source la plus utile pour isoler une interaction lente sur un modèle de page, un type d’appareil ou une étape de conversion. Des services tels que Datadog Real User Monitoring, Dynatrace Digital Experience Monitoring ou New Relic Browser proposent des capacités de suivi front-end. Une instrumentation sur mesure est également possible.

La bibliothèque open source web-vitals de Google permet de collecter les métriques Web Vitals côté navigateur. Son build d’attribution peut fournir des éléments de diagnostic complémentaires, notamment autour de l’interaction à l’origine de la valeur INP. Cette collecte doit être conçue avec les équipes juridiques et conformité : ne remontez pas de texte saisi, d’identifiants personnels, de contenu de formulaire ou d’autres données sensibles dans un outil de mesure.

Un bon schéma RUM associe la métrique à des dimensions techniques et fonctionnelles non sensibles : type de page, version de l’application, appareil, navigateur, contexte mobile ou desktop, état de consentement quand cela est pertinent, et nom stable du composant déclencheur. Un événement intitulé product-filter est exploitable ; un sélecteur CSS généré aléatoirement ou une URL complète avec paramètres personnels ne l’est pas forcément.

Le laboratoire : indispensable pour reproduire, insuffisant pour conclure

Lighthouse, Chrome DevTools et WebPageTest restent essentiels. Ils permettent de reproduire un scénario, de lire une trace de performance, d’observer le thread principal et de vérifier un correctif avant déploiement. Mais un audit de laboratoire ne peut pas simuler exactement les interactions variées de milliers de visiteurs sur leurs appareils réels.

Lighthouse affiche notamment le Total Blocking Time (TBT). Le TBT n’est pas l’INP, mais il constitue un indicateur de laboratoire utile pour détecter les longues tâches qui peuvent nuire à la réactivité. Une amélioration du TBT ne garantit pas mécaniquement une bonne INP terrain. À l’inverse, une INP CrUX dégradée ne sera pas toujours évidente sur un unique test synthétique.

CrUX indique qu’un problème existe à l’échelle du trafic observé. Le RUM aide à savoir où et pour qui il se produit. Les outils de laboratoire permettent ensuite de le reproduire et de le corriger.

Construire un diagnostic terrain centré sur les pages SEO

Le premier réflexe est souvent d’auditer la page d’accueil. Ce n’est pas toujours le meilleur point de départ. Il faut prioriser les modèles de pages qui reçoivent des impressions et des clics organiques, puis les interactions qui conditionnent la poursuite du parcours.

Commencez par croiser les données de Search Console avec votre analytics et votre RUM. Constituez une liste de modèles prioritaires : catégories, fiches produit, comparatifs, pages locales, articles à fort trafic, pages de fonctionnalités ou pages tarifaires. Pour chacun, documentez les actions attendues sur mobile et desktop.

Une fiche de diagnostic peut contenir les éléments suivants :

• le modèle d’URL et la zone concernée ;
• l’interaction : ouvrir le menu, appliquer un filtre, lancer une recherche, passer une image, envoyer un formulaire ;
• le volume de sessions ou d’utilisateurs concernés ;
• la distribution INP, avec le 75e percentile ;
• les navigateurs et familles d’appareils les plus affectés ;
• la version du front-end ou la date de déploiement ;
• les scripts, tags et composants présents sur le parcours ;
• le résultat métier attendu : navigation, consultation, ajout au panier ou conversion.

Cette priorisation évite de consacrer une semaine à optimiser un carrousel peu consulté alors que le bouton de filtre mobile ralentit la navigation de milliers de visiteurs. Elle évite aussi de confondre une URL isolée avec un défaut de template déployé sur des centaines de pages indexables.

Dans le RUM, comparez les segments au lieu de regarder une valeur globale. Une bonne INP sur ordinateur peut masquer un problème marqué sur des téléphones moins puissants. De même, un parcours connecté peut charger davantage de modules qu’un parcours anonyme. Les écarts par navigateur peuvent révéler une implémentation spécifique, tandis qu’un pic apparu après une mise en production oriente immédiatement l’enquête vers un changement récent.

Identifier les scripts et interactions responsables des latences

Une fois une interaction suspecte identifiée, reproduisez-la dans Chrome DevTools sur un environnement aussi proche que possible de la production. Ouvrez l’onglet Performance, enregistrez le scénario et réalisez l’action de manière explicite : cliquez sur le filtre, ouvrez le menu, sélectionnez une variante ou soumettez le formulaire. Répétez le test pour éviter de diagnostiquer une anomalie ponctuelle.

Dans la trace, recherchez d’abord le moment où l’interaction est enregistrée, puis examinez l’activité du thread principal avant et après celle-ci. Les éléments à inspecter sont notamment :

• les longues tâches JavaScript ;
• les appels de fonctions répétitifs ou coûteux ;
• le parsing, la compilation et l’exécution de gros bundles ;
• les recalculs de styles et opérations de layout ;
• les mutations du DOM sur un grand nombre de nœuds ;
• le chargement ou l’initialisation d’un script tiers ;
• les mises à jour de framework qui rendent inutilement une zone étendue de l’interface.

Les tags tiers sont une source régulière de concurrence sur le thread principal. Un gestionnaire de consentement, un outil d’A/B testing, une solution de personnalisation, un chat, un pixel publicitaire ou un lecteur externe peut être justifié du point de vue métier, mais son coût doit être mesuré. La bonne question n’est pas « faut-il supprimer tous les tags ? », mais « ce tag est-il nécessaire sur cette page et doit-il s’exécuter avant cette interaction ? ».

Une approche efficace consiste à établir un inventaire des scripts par modèle de page. Pour chaque script, notez son propriétaire, son objectif, les pages sur lesquelles il s’exécute, son mode de chargement et son impact observé dans les traces. Google Tag Manager peut faciliter le déploiement de balises, mais il ne rend pas leur coût nul. Un conteneur chargé de tags déclenchés sans gouvernance peut dégrader la réactivité, même si chaque ajout paraît mineur isolément.

Sur une interface de filtres, par exemple, le problème peut provenir de plusieurs couches cumulées : un écouteur lance le filtrage, une application reconstruit la grille de produits, des compteurs sont recalculés, un script de tracking écoute le même clic, puis une bibliothèque de personnalisation modifie à son tour la page. La trace permet de séparer ces responsabilités au lieu d’attribuer indistinctement le problème au « JavaScript ».

Plan de correction : JavaScript, rendu et chargement des tiers

Les correctifs doivent répondre à la cause observée. Réduire le poids total d’une page peut être bénéfique, mais ne corrige pas nécessairement une interaction qui bloque le rendu. Voici les leviers les plus fréquents.

Découper le travail long et hiérarchiser l’action visible

Lorsqu’un clic déclenche un calcul important, découpez le travail pour laisser le navigateur peindre le retour visuel attendu. L’interface peut afficher immédiatement l’ouverture d’un panneau, l’état actif d’un filtre ou un indicateur de chargement, puis traiter les calculs secondaires par étapes. Les API telles que requestAnimationFrame, setTimeout ou requestIdleCallback peuvent aider selon le cas, mais leur usage doit être validé dans le contexte réel de l’application.

Pour des calculs lourds qui ne nécessitent pas d’accéder au DOM, les Web Workers peuvent déplacer une partie du travail hors du thread principal. Ils ne constituent pas une solution universelle : la sérialisation des données et la coordination avec l’interface ont aussi un coût. Ils sont surtout pertinents lorsqu’un traitement CPU significatif est clairement identifié.

Réduire les rendus et mises en page inutiles

Un gestionnaire d’événement performant peut être suivi d’un rendu coûteux. Limitez les mises à jour à la zone réellement modifiée, évitez de reconstruire une longue liste pour un simple changement d’état et vérifiez les clés, mémorisations ou mécanismes de rendu proposés par votre framework. Dans tous les cas, la règle est la même : ne pas mettre à jour davantage de DOM que nécessaire.

Évitez également les lectures et écritures de propriétés de mise en page alternées dans une boucle, car elles peuvent provoquer des recalculs forcés. Regrouper les lectures, puis les écritures, réduit ce risque. Les animations devraient privilégier les propriétés généralement moins coûteuses à animer, telles que transform et opacity, plutôt que des changements répétés de dimensions ou de position qui imposent davantage de calculs.

Différer les fonctionnalités secondaires et contrôler les tiers

Chargez au moment utile les modules qui ne sont pas nécessaires au parcours initial. Une carte interactive peut être initialisée après une action explicite. Un chat peut être différé. Un carrousel hors écran n’a pas besoin d’exécuter immédiatement toute sa logique. Cette logique de chargement conditionnel doit toutefois préserver l’accessibilité et le fonctionnement sans interaction préalable lorsque le contenu est essentiel.

Pour les tiers, mettez en place une gouvernance claire : propriétaire interne, finalité, pages autorisées, condition de déclenchement, date de revue et métriques suivies. Retirez les balises abandonnées et limitez les doublons entre outils. Avant de différer un script de consentement ou de mesure, assurez-vous que le changement respecte les obligations applicables et les besoins de collecte réellement validés.

Valider les gains sans se tromper de métrique

La validation se déroule en plusieurs temps. En préproduction, refaites le scénario dans DevTools et comparez les traces avant et après correction. Vérifiez que l’interaction produit toujours le résultat attendu, que le suivi analytique reste fonctionnel et qu’aucune régression d’accessibilité ou de conversion n’est introduite.

Après déploiement, surveillez le RUM sur les mêmes segments que lors du diagnostic : interaction, page, mobile ou desktop, navigateur et version applicative. Ne vous contentez pas d’une médiane générale. Regardez les percentiles élevés, les appareils les moins performants et le volume de sessions concernées. Une correction utile doit améliorer le parcours réel, pas seulement un scénario de démonstration exécuté sur un poste de développement puissant.

Enfin, laissez le temps aux données CrUX et au rapport Core Web Vitals de Search Console de refléter le changement. Leur fenêtre de collecte n’est pas instantanée. Une demande de validation dans Search Console est pertinente lorsque la correction est déployée sur les URL concernées, mais elle ne remplace pas le suivi RUM quotidien ou hebdomadaire.

Documentez chaque intervention : problème observé, hypothèse, trace associée, correctif, date de mise en production et résultat mesuré. Cette discipline permet de détecter les régressions lors d’un nouveau tag marketing, d’une refonte de composant ou d’une mise à jour de framework. Elle transforme l’INP en indicateur de qualité de livraison, plutôt qu’en alerte consultée uniquement lorsque Search Console signale un problème.

Conclusion : faire de l’INP un contrôle de parcours, pas un simple score

Une mauvaise INP est rarement une fatalité technique abstraite. Elle correspond généralement à une action identifiable qui attend derrière un script, un rendu trop large, une longue tâche ou un tag tiers mal placé. Les données CrUX permettent d’alerter sur la qualité terrain, le RUM relie le problème à un usage concret, et les traces de laboratoire donnent les moyens de corriger précisément.

Commencez par vos pages organiques les plus stratégiques et par les interactions qui permettent aux visiteurs d’avancer : naviguer, rechercher, filtrer, comparer ou convertir. En mesurant ces parcours avant et après chaque intervention, vous améliorerez une expérience réellement vécue tout en consolidant les signaux de performance suivis par Google.