Corriger l'INP avec un agent IA : la métrique que les outils de lab data ne peuvent pas mesurer

Interaction to Next Paint est le Core Web Vital le plus difficile pour les agents IA. Impossible de le simuler. Lighthouse n'a pas de score INP. Sans données d'utilisateurs réels, un agent IA ne peut pas vous dire quelle interaction est lente, qui la subit, ni à quel moment du cycle de vie de la page elle a lieu. C'est ainsi que vous corrigez l'INP avec des field data.

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, taps, touches du clavier. Il retient la pire interaction de toute la session. Le mot clé est réel. Un utilisateur clique sur un menu déroulant de filtres sur la page produit pendant qu'un script analytics tiers s'exécute. Ce délai de 380 ms devient l'INP de la session.

Aucun outil de lab data ne peut reproduire cela. Lighthouse utilise le Total Blocking Time comme proxy, mais le TBT mesure le blocage du main thread pendant le chargement de la page. L'INP mesure le temps de réponse à des interactions survenant à des moments imprévisibles tout au long de la session. Une page avec un TBT nul peut quand même avoir un INP catastrophique si un timer en arrière-plan se déclenche au mauvais moment. Sans field data, un agent est aveugle à cela. Il optimise le TBT et crie victoire pendant que de vrais utilisateurs attendent 400 ms que leurs clics soient pris en compte.

Trois phases, trois fix différents

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

Input Delay : Le main thread était occupé lorsque l'utilisateur a interagi. Pendant l'état loading, les causes habituelles sont l'exécution de gros bundles JavaScript, l'initialisation de scripts analytics ou l'hydratation du framework. À l'état complete (page entièrement chargée), la faute revient aux timers en arrière-plan, aux scripts tiers qui font du polling pour vérifier les mises à jour, ou à l'activité d'un service worker.

Processing : L'event handler lui-même est trop lent. Layout thrashing (lecture du DOM, écriture dans le DOM, lecture du DOM en boucle), requêtes synchrones sur le DOM dans le handler, re-renders coûteux, ou tout simplement trop de travail dans une seule tâche sans yielding.

Presentation : Le navigateur met trop de temps à effectuer le paint après la fin du handler. Arbres DOM volumineux (des milliers de nœuds nécessitant un recalcul de style), absence de CSS containment, ou opérations de paint coûteuses déclenchées par les modifications du DOM dans le handler.

Quel script bloque la page

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

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

Au lieu d'un « votre page est lente », vous obtenez « ce fichier, cette fonction, cette durée ». Comparez cela avec Lighthouse, qui indique un Total Blocking Time de 450 ms et vous laisse chercher lequel de vos 30 scripts en est la cause.

L'agent ouvre le fichier, lit le code et écrit le fix : le différer, le découper en tâches plus courtes, ou le supprimer si personne n'en a besoin.

Loading vs loaded : deux problèmes différents

Que l'interaction ait eu lieu pendant l'état loading ou complete change totalement le fix.

Si l'INP est mauvais uniquement pendant l'état loading, le problème vient de l'ordre de chargement des scripts. Trop de JavaScript s'exécute avant que la page ne devienne interactive. Le fix passe par le chargement différé des scripts : différer les scripts non critiques, faire du code-splitting, réduire le JavaScript bloquant pour le parser.

Si l'INP est mauvais à l'état complete, il s'agit d'un problème de JavaScript au runtime. Quelque chose tourne en arrière-plan sur une page pourtant entièrement chargée. Des scripts tiers qui font du polling pour vérifier les mises à jour, des scripts analytics qui envoient des beacons, ou votre propre code qui lance des opérations lourdes via un timer.

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

Raisonnement proportionnel pour l'INP

L'INP est de 350 ms sur la page de commande. Voici la décomposition des phases issue des field data :

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

La Presentation est le goulot d'étranglement. 200 ms ne semble pas alarmant pris isolément. Mais cela représente 57 % du total. Corriger la Presentation a bien plus d'impact qu'optimiser l'Input Delay et le Processing réunis.

Sans ces pourcentages, un agent s'attaque à l'Input Delay sous prétexte que 70 ms dépassent un certain seuil. Donnez-lui la décomposition et il visera directement les 57 %. Résultat : un seul fix fait descendre l'INP sous les 200 ms, contre trois interventions dispersées qui le font à peine bouger.

Fix types par phase

Input Delay pendant le chargement : Différez les scripts non critiques. Supprimez le JavaScript inutilisé. Faites du code-splitting pour ne charger que le code utile à la page courante.

Input Delay à l'état complete : Auditez les scripts tiers qui s'exécutent après le chargement de la page. Utilisez les données LoAF de CoreDash pour identifier le script responsable. Différez son exécution sur les périodes d'inactivité avec requestIdleCallback.

Processing : Faites un yield vers le main thread avec scheduler.yield() ou setTimeout(0). Découpez les event handlers trop longs en tâches plus courtes. Évitez les forced layouts (lire des propriétés de layout immédiatement après avoir écrit dans le DOM).

Presentation : Utilisez content-visibility: auto pour les sections volumineuses du DOM sous la ligne de flottaison (pris en charge par tous les navigateurs majeurs depuis septembre 2025). Réduisez le nombre de nœuds du DOM affectés par les modifications du handler. Utilisez le CSS containment pour isoler le repaint à une zone plus restreinte.

Vérifier avec les field data

Les gains sur l'INP apparaissent dans CoreDash après un jour ou deux de trafic réel. Filtrez sur la même page et le même segment d'appareils. Le p75 doit baisser et la répartition des phases doit basculer.

Surveillez aussi la répartition par état de chargement. Si votre fix visait l'INP à l'état loading, confirmez que les chiffres s'améliorent sur cet état sans régression sur l'état complete. Les field data offrent cette granularité. Pas les lab data.