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

Interaction to Next Paint est le Core Web Vital le plus difficile pour les agents d'IA. Il ne peut pas être simulé. Lighthouse n'a pas de score INP. Un agent d'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 avez des données de terrain.

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

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

L'INP mesure la rapidité avec laquelle votre site répond aux interactions des utilisateurs : clics, appuis, pressions de touches. Il sélectionne la pire interaction de toute la session. Le mot clé est réel. Un utilisateur clique sur une liste déroulante de filtres sur votre page produit pendant qu'un script d'analyse tiers s'exécute. Ce délai de 380ms 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 nul peut tout de 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 à cela. Il optimise le TBT et crie victoire pendant que les vrais utilisateurs attendent 400ms pour que leurs clics soient enregistrés.

Trois phases, trois correctifs différents

L'INP se décompose en trois phases. Chacune implique un correctif différent.

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 paquets 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 à l'intérieur du gestionnaire, les re-rendus coûteux, ou simplement le fait de faire trop de travail dans une seule tâche sans yielding.

Presentation : Le navigateur met trop de temps à s'afficher une fois le gestionnaire terminé. Arbres DOM de grande taille (des milliers de nœuds nécessitant un recalcul de style), absence de confinement CSS, ou 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 corriger réellement l'INP au lieu de deviner.

Le LoAF nomme le fichier JavaScript exact, la fonction et la durée. L'agent ne devine pas quel script bloque le thread principal. CoreDash lui dit : gtm-container.js a bloqué le thread principal pendant 280ms 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 dit que le Total Blocking Time est de 450ms et vous laisse deviner lequel de vos 30 scripts en est la cause.

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

En chargement vs chargé : deux problèmes différents

Que l'interaction se soit produite pendant l'état loading ou complete modifie entièrement le correctif.

Si l'INP n'est mauvais que pendant l'état de chargement, le problème vient de l'ordre de chargement des scripts. Trop de JavaScript s'exécute avant que la page ne soit interactive. Le correctif réside dans le report des scripts : différer les scripts non critiques, diviser le code (code-split), réduire le JavaScript bloquant 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 d'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 350ms sur la page de paiement. La répartition des phases à partir des données de terrain :

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

La Presentation est le goulot d'étranglement. 200ms ne semble pas alarmant en soi. Mais cela représente 57 % du total. Corriger la Presentation fait plus avancer les choses que d'optimiser l'Input Delay ou le Processing réunis.

Sans les pourcentages, un agent poursuit l'Input Delay car 70ms dépasse un certain seuil. Montrez-lui la répartition et il va directement vers les 57 %. Le résultat : un correctif qui fait chuter l'INP en dessous de 200ms contre trois correctifs dispersés qui le font à peine bouger.

Correctifs typiques par phase

Input Delay pendant le chargement : Différez les scripts non critiques. Supprimez le JavaScript inutilisé. Divisez le code 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 fautif. Différez-le aux moments d'inactivité avec requestIdleCallback.

Processing : Effectuez un yielding 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 réaffichage (repaint) sur une zone plus petite.

Vérification avec les données de terrain

Les améliorations de l'INP apparaissent dans CoreDash au bout d'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 décaler.

Surveillez également la répartition de l'état de chargement. Si votre correctif ciblait 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 ne le font pas.