Trouver et corriger les problèmes d'Interaction to Next Paint (INP) : un guide étape par étape
Apprenez à identifier et à corriger les problèmes d'Interaction to Next Paint à l'aide de données de RUM, des Chrome DevTools et de l'API LoAF
Trouver et corriger les problèmes d'Interaction to Next Paint (INP)
Cette page fait partie de notre série sur l'Interaction to Next Paint (INP). L'INP mesure la réactivité de votre site web en suivant le délai entre une interaction utilisateur et la mise à jour visuelle suivante. Un bon score INP est inférieur à 200 millisecondes, tandis que les scores supérieurs à 500 millisecondes sont considérés comme médiocres. Si vous découvrez l'INP, commencez par la page d'accueil de l'INP pour une vue d'ensemble complète.
Selon le 2025 Web Almanac, 23 % des origines mobiles échouent encore à l'INP. Si votre site en fait partie, voici le processus : confirmer le problème dans la Search Console, diagnostiquer les causes racines avec les données de Real User Monitoring (RUM), reproduire localement et appliquer des correctifs ciblés à chaque phase de l'INP.
CONSEIL INP : la plupart du temps, l'INP sera bien pire
lorsqu'un utilisateur interagit avec la page pendant la phase de démarrage du
chargement de la page. C'est pourquoi, lors du débogage de l'INP,
il est logique de journaliser toutes les interactions ainsi que l'état de chargement de la page !
Table of Contents!
Étape 1 : Vérifier l'INP dans la Search Console
La première étape consiste à confirmer que vous avez réellement un problème d'INP. Avant d'apporter des modifications au code, vérifiez le problème dans la Google Search Console afin de travailler à partir de données de terrain réelles plutôt que sur des suppositions.
Connectez-vous à votre Google Search Console. Dans le menu de gauche, cliquez sur Core Web Vitals et sélectionnez soit Mobile, soit Desktop (conseil : la plupart du temps, les problèmes d'INP apparaissent d'abord sur mobile, alors commencez par là).
Ici, vous verrez un aperçu de tous les problèmes liés aux Core Web Vitals actuellement présents sur votre site. Si l'un de ces problèmes est lié à l'INP, vous avez la confirmation qu'il y a un problème.
Étape 2 : Identifier les problèmes d'Interaction to Next Paint
La Google Search Console ne vous donne aucune information en dehors des groupes d'URLs pour comprendre ce qui cause les problèmes avec l'Interaction to Next Paint. Ainsi, la plupart du temps, les développeurs y vont à l'aveugle. Ils commencent par supprimer le JavaScript inutilisé (toujours une excellente idée) et par diviser le main thread (également une excellente idée), mais cela ne corrige presque jamais l'INP complètement.
C'est pourquoi, pour améliorer l'INP, nous devons savoir exactement ce qui se passe. Nous avons besoin de réponses à quatre questions critiques :
Quels éléments, lors d'une interaction, provoquent un mauvais score INP ?
Généralement, un mauvais score INP n'est pas causé par un seul élément mais par une combinaison de problèmes. Nous devons
les traiter un par un, en commençant par les pires et en remontant.
Quand ces interactions se produisent-elles ? Se produisent-elles
pendant la phase de démarrage du
chargement de la page, ou se produisent-elles même lorsque la page principale est entièrement chargée ?
Où ces
interactions se produisent-elles ? Se produisent-elles sur chaque page, ou se produisent-elles
uniquement sur quelques pages sélectionnées ?
Comment pouvons-nous reproduire
ces interactions ? Vous avez peut-être déjà découvert qu'il
est difficile de reproduire les problèmes d'INP. C'est pourquoi nous devons nous mettre en condition de réussite en
imitant les caractéristiques des appareils ayant un mauvais score INP.
Configurer le suivi RUM
Pour répondre à toutes ces questions, nous devons commencer à suivre les utilisateurs réels et journaliser tous les problèmes qui
pourraient survenir avec l'Interaction to Next Paint. Il existe plusieurs façons d'activer le suivi RUM. La
première consiste à utiliser la bibliothèque web-vitals et à envoyer les résultats à votre propre backend d'analyse.
L'avantage de cette méthode est qu'elle est peu coûteuse et flexible. L'inconvénient est qu'elle peut représenter beaucoup
de travail supplémentaire.
Une bonne alternative à l'envoi de vos données Core Web Vitals à votre propre backend consiste à utiliser l'un des nombreux outils de RUM disponibles. Nous avons développé CoreDash précisément pour ces cas d'utilisation. CoreDash est un outil de RUM peu coûteux, rapide et efficace qui fait le travail. Bien sûr, il existe de nombreuses autres solutions de RUM et elles feront également le travail (à un prix plus élevé cependant).
Trouver les interactions lentes par élément qui causent un INP élevé
Commencez par trouver les interactions les plus lentes qui causent les pires scores INP. Listez vos pages par "INP metric by Elements" dans CoreDash et vous obtiendrez vos interactions les plus lentes. Cliquez sur la première ligne pour filtrer vos métriques par ces interactions.
Trouver quand les mauvaises interactions INP se produisent
Ensuite, triez les URLs filtrées par état de chargement (load state). Cela vous donnera plus d'informations sur la cause racine de l'INP. Dans ce cas, l'INP élevé se produit lorsque le contenu DOM a été chargé. Cela signifie que les scripts ont été analysés mais que les scripts asynchrones et les sous-ressources de la page n'ont pas encore été chargés. Dans ce cas, l'INP est causé par des clics précoces alors que le chargement de la page n'est pas complètement terminé.
Continuez en cliquant sur l'état de chargement ayant le plus d'impact pour créer un autre filtre.
Trouver les URLs responsables des scores INP élevés
Enfin, lorsque nous avons filtré pour les éléments ayant l'interaction la plus lente et le bon état de chargement, nous allons jeter un œil aux URLs où l'INP est à son pire. Dans ce cas, cela se produit clairement sur un ensemble spécifique de pages.
Trouver les caractéristiques de l'appareil
Lorsque nous avons identifié les interactions lentes, l'état de chargement et les URLs qui causent une Interaction to Next Paint élevée, nous allons regarder quels types de visiteurs provoquent les pires scores INP. Nous regarderions la mémoire de l'appareil (Device Memory), la bande passante, la taille de l'écran et d'autres caractéristiques matérielles. Une fois que nous avons identifié ces caractéristiques, nous pouvons passer à la reproduction et à la journalisation du problème.
Utiliser l'API Long Animation Frames (LoAF) pour le diagnostic de l'INP
L'API Long Animation Frames (LoAF) vous indique exactement quels scripts et fonctions causent des interactions lentes. Contrairement à l'ancienne API Long Tasks, LoAF fournit les URLs des scripts, les noms des fonctions et les décompositions de temps par frame. Elle est particulièrement utile lorsqu'elle est combinée avec les données de RUM d'un outil comme CoreDash.
Cet observateur collecte les entrées LoAF pour les frames de plus de 50 ms, capturant l'attribution du script, la durée et le temps de blocage :
\/\/ Observe les Long Animation Frames pour l'attribution de l'INP
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
\/\/ Ne journalise que les frames de plus de 50 ms
if (entry.duration > 50) {
console.log('Long Animation Frame:', {
duration: entry.duration,
blockingDuration: entry.blockingDuration,
renderStart: entry.renderStart,
styleAndLayoutStart: entry.styleAndLayoutStart,
scripts: entry.scripts.map(script => ({
sourceURL: script.sourceURL,
sourceFunctionName: script.sourceFunctionName,
invokerType: script.invokerType,
invoker: script.invoker,
duration: script.duration
}))
});
}
}
});
observer.observe({ type: 'long-animation-frame', buffered: true });
L'API LoAF révèle quels scripts contribuent à chaque phase de l'INP. Le tableau scripts vous indique le fichier source exact et le nom de la fonction, tandis que renderStart et styleAndLayoutStart vous aident à séparer le temps de traitement (processing time) du délai de présentation (presentation delay). LoAF est actuellement réservé à Chromium (Chrome 123+), donc pour le débogage sur Firefox et Safari, appuyez-vous plutôt sur la trace du panneau Performance et les données de RUM. Pour en savoir plus sur la façon dont le chargement JavaScript async vs defer affecte ces timings, consultez notre guide dédié.
Étape 3 : Reproduire et déboguer les interactions qui causent un score INP élevé
Avec ces données en main, nous pouvons commencer à corriger les causes racines.
Préparez-vous au succès : reproduisez les circonstances d'échec de l'INP
La chose suivante que nous devrions faire est d'essayer de recréer l'échec de l'INP. Nous faisons cela en imitant les circonstances dans lesquelles l'INP pourrait échouer.
Utilisez le panneau Performance de Chrome : Ouvrez les outils pour développeurs de Chrome (Ctrl+Shift+I) et sélectionnez le
panneau Performance. Dans la barre supérieure, vous pouvez sélectionner le CPU Throttle (limitez-le à un ralentissement de 4x pour
émuler un appareil mobile normal), le Network Throttle (sélectionnez le préréglage "Fast 3G" pour imiter votre
appareil mobile moyen), et réglez la simultanéité matérielle (hardware concurrency) à 4 ou 8 pour imiter votre appareil mobile moyen.
Pour charger Chrome avec moins de mémoire disponible (bien que l'abaissement des paramètres réseau et CPU fasse souvent l'affaire), démarrez Chrome dans un conteneur Docker et allouez moins de mémoire.
Rechargez la page, interagissez et vérifiez l'INP avec le visualiseur Core Web Vitals
Maintenant, simulez les conditions et confirmez que les scores INP correspondent à ce que vos données de RUM ont rapporté.
Rechargez la page et cliquez sur le bon élément au bon moment
Déboguer l'INP avec une trace de performance
C'est le moment que vous avez préparé lors des étapes précédentes. Il est temps de découvrir pourquoi une certaine interaction provoque le mauvais score d'Interaction to Next Paint.
Ouvrez la console développeur de Chrome (Ctrl+Shift+I), accédez au panneau Performance et cette fois, cliquez sur l'icône de flèche circulaire pour recharger la page et commencer l'enregistrement (ou utilisez le raccourci Ctrl+Shift+E). Pendant que l'enregistrement est en cours, interagissez avec l'élément qui cause le mauvais INP. Après quelques secondes, arrêtez l'enregistrement et examinez la chronologie. Recherchez l'événement d'interaction dans la piste "Interactions", puis inspectez les tâches correspondantes dans la piste "Main" pour voir exactement quel code s'exécute pendant chaque phase.
Lire la trace de performance
Dans le panneau Performance de Chrome, l'interaction apparaîtra sous forme de barre colorée dans la piste "Interactions". Cliquez dessus pour voir la durée totale de l'INP et sa décomposition. En dessous, dans la piste "Main", vous pouvez voir les tâches individuelles qui ont été exécutées pendant l'interaction. Prêtez attention aux :
- Tâches avant le gestionnaire d'événements : elles contribuent à l'input delay
- Le gestionnaire d'événements lui-même : c'est le temps de traitement (processing time)
- Le travail de rendu après la fin du gestionnaire : c'est le délai de présentation (presentation delay)
Comparez ces résultats avec vos données LoAF pour confirmer que les scripts identifiés dans la trace correspondent aux données d'attribution de votre outil de RUM. C'est aussi le bon moment pour vérifier si des gestionnaires de scroll JavaScript contribuent au problème.
Étape 4 : Corriger les problèmes d'INP
Vous savez quelle interaction est lente et pourquoi. Il est temps de la corriger. L'Interaction to Next Paint peut être décomposée en 3 phases : l'input delay, le processing time, et le presentation delay.
Chaque phase nécessite une approche différente. Voici un résumé. Suivez les liens pour les guides d'optimisation complets.
Minimiser l'input delay :
L'input delay est le temps écoulé entre l'interaction avec la page et le moment où la callback de l'événement commence à s'exécuter. Bien qu'un certain input delay soit inévitable (les navigateurs ont besoin de temps pour planifier les callbacks), vous pouvez le minimiser :
- Éviter les tâches longues. Chaque fois qu'une tâche s'exécute, elle bloque le main thread et laisse les callbacks d'événements en attente. C'est particulièrement important lors de l'optimisation des clics précoces (car la plupart des scripts s'exécuteront à ce moment-là). Pour des stratégies visant à réduire le blocage JavaScript, consultez notre guide sur le chargement JavaScript async vs defer.
- Être prudent lors de la création de nouvelles tâches. Par exemple, les tâches récurrentes via
setTimeout()ou les tâches qui se produiront probablement avant l'événement INP comme les callbacks sur l'événementmouseover. - Mesurer et évaluer l'interaction précoce. Lorsqu'un élément interactif est présenté tôt (par exemple un élément de recherche sur le site) et est contrôlé par du JavaScript qui se charge plus tard, toute interaction avec l'élément ne déclenchera pas de mise à jour immédiate de la mise en page. Priorisez la fonctionnalité ou masquez/désactivez l'élément avant qu'il ne fonctionne correctement.
- Utiliser les web workers pour exécuter le JavaScript en dehors du main thread du navigateur. Les web workers permettent aux scripts de s'exécuter en dehors du main thread. Cela empêchera le main thread de se bloquer et de causer des problèmes d'input delay de l'INP.
- Charger les scripts tiers non essentiels pendant le temps d'inactivité (idle time) du navigateur. Certains scripts sont plus critiques que d'autres. Il est logique de prioriser ces scripts et de charger les scripts moins importants pendant le temps d'inactivité du navigateur. Par exemple, un script de chat. Consultez notre guide sur les 14 méthodes pour différer le JavaScript pour des techniques pratiques.
Minimiser le temps de traitement (processing time)
- Supprimer le code inutile. Le code inutile est soit du code plus ancien qui s'exécute toujours, soit du nouveau code qui n'est pas nécessaire sur cette page spécifique mais qui consomme toujours du temps CPU. C'est de loin le moyen le plus simple d'améliorer immédiatement l'INP.
- Différer le code qui n'a pas besoin de s'exécuter avant le prochain affichage (paint). Divisez le code en code critique qui doit s'exécuter avant l'INP et code non critique (par exemple l'envoi d'analyses) et planifiez cela après l'événement de paint avec la méthode
requestIdleCallback(). - Optimiser le code qui doit s'exécuter avant l'affichage (paint). Vérifiez votre code et réécrivez les parties lentes ou inefficaces.
- Fournir un retour immédiat. Sur les tâches compliquées ou potentiellement lentes, fournissez un retour visuel immédiat avant d'exécuter le code principal.
Minimiser le délai de présentation (presentation delay)
- Garder le DOM petit et simple. Il sera beaucoup plus facile pour un navigateur de rendre une page avec des éléments DOM (nœuds HTML) peu nombreux, simples et non imbriqués qu'il ne l'est de rendre une page avec de nombreux nœuds DOM imbriqués. En savoir plus sur la correction de la taille excessive du DOM.
- Utiliser content-visibility pour le rendu différé (lazy-render) du contenu hors écran. Content-visibility accélérera le rendu des parties visibles de la page en retardant le rendu du contenu hors écran et en le rendant juste à temps.
Correctif rapide : céder le contrôle au main thread avec scheduler.yield()
Céder le contrôle (yielding) au main thread entre le travail critique et non critique améliore les trois phases de l'INP à la fois. L'API scheduler.yield() offre un moyen propre de le faire. Voici une fonction d'aide réutilisable avec un fallback pour les navigateurs qui ne supportent pas encore l'API :
async function yieldToMain() {
if ('scheduler' in window && 'yield' in window.scheduler) {
return await window.scheduler.yield();
}
return new Promise((resolve) => {
setTimeout(resolve, 0);
});
}
\/\/ Utilisation dans un gestionnaire d'événements
async function handleButtonClick() {
\/\/ Travail critique : mettre à jour l'UI
updateVisualFeedback();
\/\/ Céder le contrôle pour laisser le navigateur peindre
await yieldToMain();
\/\/ Travail non critique : analyses, journalisation
sendAnalyticsEvent('button_click');
logInteraction();
}
Chaque phase de l'INP en détail
Chaque phase a ses propres stratégies d'optimisation :
- Input Delay : Apprenez à minimiser le temps entre l'interaction utilisateur et le début du traitement de l'événement. L'input delay est généralement la plus petite des trois phases, mais elle explose pendant le démarrage de la page lorsque le main thread est occupé par l'exécution des scripts.
- Processing Time : Optimisez le code du gestionnaire d'événements qui s'exécute pendant l'interaction. Sur la plupart des pages, c'est là que le gros de votre effort d'optimisation porte ses fruits.
- Presentation Delay : Réduisez le travail de rendu et de peinture qui suit le traitement de l'événement. Sur les pages complexes avec de grands DOM, c'est souvent la phase la plus importante.
Pour des stratégies supplémentaires qui touchent aux trois phases, consultez nos guides sur l'amélioration de l'INP en abandonnant le scroll JavaScript et sur le choix entre async et defer pour votre JavaScript.
17 years of fixing PageSpeed.
I have optimized platforms for some of the largest publishers and e-commerce sites in Europe. I provide the strategy, the code, and the RUM verification. Usually in 1 to 2 sprints.
View Services
