Corriger l'INP avec un agent IA : La métrique que les outils de laboratoire ne peuvent mesurer

Interaction to Next Paint est le Core Web Vital le plus difficile pour les agents IA. Il ne peut pas être simulé. Lighthouse n'a pas de score INP. Un agent IA sans données d'utilisateurs réels ne peut pas vous dire quelle interaction est lente, qui la subit, ou à quel moment du cycle de vie de la page elle se produit. Voici comment corriger l'INP lorsque vous disposez de données de terrain.

Dernière révision par Arjen Karel en mars 2026

Pourquoi l'INP est différent pour les agents IA

L'INP mesure la rapidité avec laquelle votre site répond aux interactions des utilisateurs : clics, appuis, pressions de touches. Il retient la pire interaction de toute la session. Le mot clé est réel. Un utilisateur clique sur un menu déroulant de filtre sur votre page produit pendant qu'un script d'analyse tiers s'exécute. Ce délai de 380 ms devient l'INP de cette session.

Aucun outil de laboratoire ne peut reproduire cela. Lighthouse utilise le Total Blocking Time comme indicateur, mais le TBT mesure le blocage du thread principal pendant le chargement de la page. L'INP mesure le temps de réponse aux interactions qui se produisent à des moments imprévisibles tout au long de la session. Une page avec un TBT de zéro peut quand même avoir un INP désastreux si un minuteur en arrière-plan se déclenche au mauvais moment. Un agent sans données de terrain est aveugle face à cela. Il optimise le TBT et crie victoire pendant que les vrais utilisateurs attendent 400 ms que leurs clics soient pris en compte.

Trois phases, trois corrections différentes

L'INP se décompose en trois phases. Chacune implique une correction différente.

Input Delay : Le thread principal était occupé lorsque l'utilisateur a interagi. Pendant l'état de chargement, les causes habituelles sont l'exécution de gros bundles JavaScript, l'initialisation de scripts d'analyse ou l'hydratation du framework. À l'état complet (page entièrement chargée), blâmez les minuteurs en arrière-plan, les scripts tiers interrogeant les mises à jour ou l'activité du service worker.

Processing : Le gestionnaire d'événements lui-même est trop lent. Le Layout thrashing (lire le DOM, écrire dans le DOM, lire le DOM en boucle), les requêtes DOM synchrones dans le gestionnaire, les rendus coûteux ou simplement l'exécution d'une quantité excessive de travail dans une seule tâche sans faire de yield.

Presentation : Le navigateur met trop de temps à afficher après la fin du gestionnaire. De grands arbres DOM (des milliers de nœuds nécessitant un recalcul du style), l'absence de confinement CSS, ou des opérations d'affichage coûteuses déclenchées par les modifications du DOM du gestionnaire.

Quel script bloque votre page

CoreDash capture l'attribution des Long Animation Frames (LoAF) à partir de sessions d'utilisateurs réels. C'est ce qui permet à l'agent de véritablement corriger l'INP au lieu de deviner.

LoAF nomme exactement le fichier JavaScript, la fonction et la durée. L'agent ne devine pas quel script bloque le thread principal. CoreDash le lui indique : gtm-container.js a bloqué le thread principal pendant 280 ms lors de l'interaction sur le filtre de la page de paiement.

Au lieu de "votre page est lente", vous obtenez "ce fichier, cette fonction, cette durée". Comparez cela à Lighthouse, qui vous indique que le Total Blocking Time est de 450 ms et vous laisse découvrir lequel de vos 30 scripts en est la cause.

L'agent ouvre le fichier, lit le code et rédige le correctif : le différer, le diviser en tâches plus petites ou le supprimer si personne n'en a besoin.

Chargement vs chargé : deux problèmes différents

Le fait que l'interaction se soit produite pendant l'état loading ou complete modifie entièrement la correction.

Si l'INP n'est mauvais que pendant l'état de chargement, le problème réside dans l'ordre de chargement des scripts. Trop de JavaScript s'exécute avant que la page ne soit interactive. La solution se trouve dans le report de script : différez les scripts non critiques, utilisez le code-splitting, réduisez le JavaScript qui bloque l'analyseur.

Si l'INP est mauvais à l'état complet, vous avez un problème d'exécution JavaScript. Quelque chose s'exécute en arrière-plan sur une page entièrement chargée. Des scripts tiers interrogeant les mises à jour, des outils d'analyse envoyant des balises, ou votre propre code exécutant des opérations coûteuses sur un minuteur.

CoreDash suit l'état de chargement de la page pour chaque mesure de l'INP. CWV Superpowers utilise cela pour écarter la moitié des causes avant même d'examiner les scripts.

Raisonnement proportionnel pour l'INP

L'INP est de 350 ms sur la page de paiement. La répartition des phases à partir des données de terrain :

• Input Delay : 70 ms (20 %)
• Processing : 80 ms (23 %)
• Presentation : 200 ms (57 %)

La Presentation est le goulot d'étranglement. 200 ms ne semblent pas alarmants isolément. Mais cela représente 57 % du total. Corriger la Presentation a plus d'impact que l'optimisation de l'Input Delay ou du Processing réunis.

Sans les pourcentages, un agent s'acharne sur l'Input Delay car 70 ms dépassent un certain seuil. Montrez-lui la répartition et il visera directement les 57 %. Le résultat : une seule correction qui fait chuter l'INP en dessous de 200 ms contre trois corrections éparses qui le font à peine bouger.

Corrections typiques par phase

Input Delay pendant le chargement : Différez les scripts non critiques. Supprimez le JavaScript inutilisé. Utilisez le code-splitting pour que seul le code de la page actuelle se charge.

Input Delay à l'état complet : Auditez les scripts tiers s'exécutant après le chargement de la page. Utilisez les données LoAF de CoreDash pour trouver le script coupable. Différez-le aux périodes d'inactivité avec requestIdleCallback.

Processing : Faites un yield vers le thread principal avec scheduler.yield() ou setTimeout(0). Divisez les longs gestionnaires d'événements en tâches plus petites. Évitez les mises en page forcées (lire les propriétés de mise en page immédiatement après avoir écrit dans le DOM).

Presentation : Utilisez content-visibility: auto pour les grandes sections du DOM sous la ligne de flottaison (pris en charge par tous les principaux navigateurs depuis septembre 2025). Réduisez le nombre de nœuds DOM affectés par les modifications du gestionnaire. Utilisez le confinement CSS pour isoler le redessin à une zone plus petite.

Vérification avec les données de terrain

Les améliorations de l'INP apparaissent dans CoreDash en un jour ou deux de trafic réel. Interrogez la même page et le même segment d'appareil. Le p75 devrait baisser et la distribution des phases devrait se modifier.

Surveillez également la répartition de l'état de chargement. Si votre correction visait l'INP à l'état de chargement, confirmez que les chiffres de l'état de chargement se sont améliorés sans faire régresser les chiffres de l'état complet. Les données de terrain vous offrent cette granularité. Les données de laboratoire non.