Identifier et corriger les problèmes d'Interaction to Next Paint (INP) : guide étape par étape Identifier et corriger les problèmes d'Interaction to Next Paint (INP) : guide étape par étape
Learn how to identify and fix Interaction to Next Paint issues using RUM data, Chrome DevTools, and the LoAF API
Identifier 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 de l'utilisateur et la mise à jour visuelle suivante. Un bon score INP est inférieur à 200 millisecondes, tandis qu'un score supérieur à 500 millisecondes est considéré comme médiocre. Si vous découvrez l'INP, commencez par la page centrale 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 la démarche : confirmez le problème dans la Search Console, diagnostiquez les causes profondes avec des données RUM, reproduisez le problème localement et appliquez des corrections ciblées à chaque phase de l'INP.
ASTUCE INP : la plupart du temps, l'INP est 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 judicieux d'enregistrer 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 de modifier le code, vérifiez le problème dans Google Search Console afin de vous baser sur de vraies field data plutôt que sur des hypothèses.
Connectez-vous à votre Google Search Console. Dans le menu de gauche, cliquez sur Core Web Vitals et sélectionnez Mobile ou Desktop (astuce : la plupart du temps, les problèmes d'INP apparaissent d'abord sur mobile, commencez donc par là).
Vous verrez ici 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 concerne l'INP, vous avez la confirmation qu'il y a un problème.
Étape 2 : Identifier les problèmes d'Interaction to Next Paint
Google Search Console ne fournit aucune information en dehors des groupes d'URL pour comprendre ce qui cause les problèmes d'Interaction to Next Paint. La plupart du temps, les développeurs avancent donc à l'aveugle. Ils commencent par supprimer le JavaScript inutile (toujours une excellente idée) et à découper le main thread (également une excellente idée), mais cela résout rarement l'INP complètement.
C'est pourquoi, pour améliorer l'INP, nous devons savoir exactement ce qui se passe. Nous devons répondre à quatre questions cruciales :
Quels éléments, lors d'une interaction, provoquent un mauvais score INP ?
En général, 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 plus critiques.
Quand ces interactions se produisent-elles ? Se produisent-elles
pendant la phase de démarrage du
chargement de la page, ou ont-elles lieu même lorsque la page principale est complètement chargée ?
Où ces
interactions se produisent-elles ? Se produisent-elles sur toutes les pages, ou uniquement
sur certaines d'entre elles ?
Comment pouvons-nous reproduire
ces interactions ? Vous avez probablement déjà constaté qu'il
est difficile de reproduire les problèmes d'INP. C'est pourquoi nous devons nous mettre dans les meilleures conditions
en simulant les caractéristiques des appareils qui obtiennent un mauvais score INP.
Mettre en place le suivi RUM
Pour répondre à toutes ces questions, nous devons suivre les utilisateurs réels et enregistrer tous les problèmes liés à 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 économique 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 vers votre propre backend consiste à utiliser l'un des nombreux outils RUM du marché. Nous avons développé CoreDash précisément pour ces cas d'usage. CoreDash is un outil RUM économique, rapide et efficace qui fait le travail. Bien sûr, il existe de nombreuses autres solutions RUM qui feront également l'affaire (mais à un prix plus élevé).
Trouver les interactions lentes par élément qui provoquent un INP élevé
Commencez par identifier les interactions les plus lentes qui provoquent les pires scores INP. Affichez la liste de vos pages par « INP metric by Elements » dans CoreDash pour obtenir vos interactions les plus lentes. Cliquez sur la première ligne pour filtrer vos métriques sur ces interactions.
Déterminer quand les mauvaises interactions INP se produisent
Ensuite, triez les URL filtrées par état de chargement. Cela vous donnera un meilleur aperçu de la cause profonde de l'INP. Dans ce cas, l'INP élevé se produit lorsque le contenu du 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 ne sont pas encore chargés. Dans ce cas, l'INP est causé par des clics précoces alors que le chargement de la page n'est pas entièrement terminé.
Continuez en cliquant sur l'état de chargement ayant le plus fort impact pour créer un autre filtre.
Trouver les URL responsables des scores INP élevés
Enfin, après avoir filtré les éléments avec l'interaction la plus lente et l'état de chargement correspondant, nous allons examiner les URL où l'INP est le plus mauvais. Dans ce cas, cela se produit clairement sur un ensemble spécifique de pages.
Identifier les caractéristiques des appareils
Une fois que nous avons identifié les interactions lentes, l'état de chargement et les URL qui causent un Interaction to Next Paint élevé, nous allons regarder quels types de visiteurs obtiennent les pires scores INP. Nous analyserons la mémoire de l'appareil, la bande passante, la taille de l'écran et d'autres caractéristiques matérielles. Après avoir identifié ces caractéristiques, nous pourrons passer à la reproduction et à l'enregistrement du problème.
Utiliser l'API Long Animation Frames (LoAF) pour diagnostiquer l'INP
L'API Long Animation Frames (LoAF) indique précisément quels scripts et fonctions provoquent des interactions lentes. Contrairement à l'ancienne API Long Tasks, LoAF fournit les URL des scripts, le nom des fonctions et le détail des timings par frame. Elle est particulièrement utile lorsqu'elle est combinée avec les données 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 :
// Observer les Long Animation Frames pour l'attribution de l'INP
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
// Enregistrer uniquement 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 indique le fichier source exact et le nom de la fonction, tandis que renderStart et styleAndLayoutStart vous aident à séparer le temps de traitement du délai de présentation. LoAF est actuellement réservé à Chromium (Chrome 123+). Pour le débogage sur Firefox et Safari, appuyez-vous plutôt sur le tracé du panneau Performance et sur les données RUM. Pour en savoir plus sur l'impact du chargement JavaScript avec async ou defer sur ces durées, consultez notre guide dédié.
Étape 3 : Reproduire et déboguer les interactions qui provoquent un score INP élevé
Avec ces données en main, nous pouvons commencer à corriger les causes profondes.
Mettez-vous dans les meilleures conditions : reproduisez les conditions d'échec de l'INP
La prochaine étape consiste à essayer de recréer l'échec de l'INP. Pour cela, nous simulons les circonstances dans lesquelles l'INP est susceptible d'échouer.
Utilisez le panneau Performance de Chrome : ouvrez les outils de développement de Chrome (Ctrl+Shift+I) et sélectionnez le panneau Performance. Dans la barre supérieure, vous pouvez configurer le CPU Throttle (ralentissement de 4x pour émuler un appareil mobile standard), le Network Throttle (sélectionnez le profil Fast 3G pour simuler un appareil mobile moyen) et régler le Hardware Concurrency à 4 ou 8 pour imiter un mobile classique.
Pour lancer Chrome avec moins de mémoire disponible (bien que réduire les paramètres réseau et CPU suffise généralement), démarrez Chrome dans un conteneur Docker et allouez-lui moins de mémoire.
Rechargez la page, interagissez et vérifiez l'INP avec le visualiseur de Core Web Vitals
Simulez maintenant ces conditions et vérifiez que les scores INP correspondent à ceux rapportés par vos données RUM.
Rechargez la page et cliquez sur le bon élément au bon moment
Déboguez l'INP avec un tracé de performance
C'est le moment que vous prépariez lors des étapes précédentes. Il est temps de découvrir pourquoi une interaction spécifique provoque un mauvais score d'Interaction to Next Paint.
Ouvrez la console de développement de Chrome (Ctrl+Shift+I), accédez au panneau Performance et cliquez cette fois sur l'icône de flèche circulaire pour recharger la page et démarrer l'enregistrement (ou utilisez le raccourci Ctrl+Shift+E). Pendant que l'enregistrement tourne, interagissez avec l'élément qui génère 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 durant chaque phase.
Lire le tracé de performance
Dans le panneau Performance de Chrome, l'interaction s'affiche sous forme de barre colorée dans la piste « Interactions ». Cliquez dessus pour voir la durée totale de l'INP et son détail. En dessous, dans la piste « Main », vous pouvez voir les différentes tâches exécutées lors de l'interaction. Soyez attentif aux éléments suivants :
- Tâches avant le gestionnaire d'événements : elles contribuent au délai d'entrée
- Le gestionnaire d'événements lui-même : c'est le temps de traitement
- Le travail de rendu après la fin du gestionnaire : c'est le délai de présentation
Comparez ces résultats avec vos données LoAF pour confirmer que les scripts identifiés dans le tracé correspondent aux données d'attribution de votre outil RUM. C'est également le moment idéal pour vérifier si des gestionnaires de défilement 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 se décompose en 3 phases : le délai d'entrée, le temps de traitement et le délai de présentation.
Chaque phase nécessite une approche différente. En voici un résumé. Suivez les liens pour accéder aux guides d'optimisation complets.
Minimiser le délai d'entrée :
Le délai d'entrée est le temps écoulé entre l'interaction avec la page et le début de l'exécution du callback d'événement. Bien qu'une partie du délai d'entrée soit inévitable (le navigateur ayant besoin de temps pour planifier les callbacks), vous pouvez le minimiser :
- Évitez les long tasks. Chaque fois qu'une tâche s'exécute, elle bloque le main thread et met en attente les callbacks d'événements. C'est particulièrement important lors de l'optimisation des clics précoces (car la plupart des scripts sont en cours d'exécution à ce moment-là). Pour découvrir des stratégies de réduction du blocage lié au JavaScript, consultez notre guide sur le JavaScript async vs defer.
- Soyez prudent lors de la création de nouvelles tâches. Par exemple, les tâches récurrentes via
setTimeout()ou les tâches susceptibles de se produire avant l'événement INP, comme les callbacks sur l'événementmouseover. - Mesurez et évaluez les interactions précoces. Lorsqu'un élément interactif s'affiche tôt (par exemple un moteur de recherche de site) mais est contrôlé par du JavaScript chargé plus tard, toute interaction avec cet élément ne déclenchera pas de mise à jour immédiate du layout. Donnez la priorité à cette fonctionnalité, ou masquez/désactivez l'élément tant qu'il n'est pas pleinement opérationnel.
- Utilisez des web workers pour exécuter le JavaScript en dehors du main thread du navigateur. Les web workers permettent d'exécuter des scripts hors du main thread. Cela évite de bloquer le main thread et de générer des problèmes de délai d'entrée pour l'INP.
- Chargez les scripts tiers non essentiels pendant les périodes d'inactivité du navigateur. Certains scripts sont plus critiques que d'autres. Il est logique de prioriser ces scripts et de charger ceux qui sont moins importants lorsque le navigateur est inactif. C'est le cas, par exemple, d'un script de chat. Consultez notre guide sur les 14 méthodes pour différer le JavaScript pour découvrir des techniques pratiques.
Minimiser le temps de traitement
- Supprimez le code inutile. Le code inutile désigne soit du vieux code qui s'exécute encore, soit du code récent non requis sur cette page spécifique qui consomme du temps CPU. C'est de loin le moyen le plus simple d'améliorer immédiatement l'INP.
- Différez le code qui n'a pas besoin de s'exécuter avant le prochain paint. Séparez le code en deux parties : le code critique qui doit s'exécuter avant l'INP, et le code non critique (par exemple, l'envoi d'analyses). Planifiez ce dernier après l'événement de paint à l'aide de la méthode
requestIdleCallback(). - Optimisez le code qui doit s'exécuter avant le paint. Analysez votre code et réécrivez les parties lentes ou inefficaces.
- Fournissez un retour immédiat. Pour les tâches complexes ou potentiellement lentes, proposez un retour visuel immédiat avant d'exécuter le code principal.
Minimiser le délai de présentation
- Conservez un DOM léger et simple. Il est beaucoup plus facile pour un navigateur de restituer une page contenant des éléments DOM simples et peu imbriqués (nœuds HTML) qu'une page avec de nombreux nœuds imbriqués. Découvrez comment corriger une taille de DOM excessive.
- Utilisez content-visibility pour différer le rendu du contenu hors écran. La propriété content-visibility accélère le rendu des parties visibles de la page en reportant le rendu du contenu hors écran pour ne l'exécuter qu'au dernier moment.
Correction rapide : libérer le main thread avec scheduler.yield()
Le yielding au main thread entre le travail critique et non critique améliore simultanément les trois phases de l'INP. L'API scheduler.yield() fournit une méthode propre pour y parvenir. Voici une fonction d'aide réutilisable avec un fallback pour les navigateurs qui ne prennent pas encore en charge 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 : mise à jour de l'UI
updateVisualFeedback();
// Yield pour laisser le navigateur effectuer le paint
await yieldToMain();
// Travail non critique : analyses et logs
sendAnalyticsEvent('button_click');
logInteraction();
}
Chaque phase de l'INP en détail
Chaque phase possède ses propres stratégies d'optimisation :
- Délai d'entrée : découvrez comment minimiser le temps écoulé entre l'interaction de l'utilisateur et le début du traitement de l'événement. Le délai d'entrée est généralement la plus courte des trois phases, mais il grimpe en flèche lors du démarrage de la page lorsque le main thread est accaparé par l'exécution des scripts.
- </b>Temps de traitement : optimisez le code du gestionnaire d'événements qui s'exécute lors de l'interaction. Sur la plupart des pages, c'est là que se concentre l'essentiel de vos gains d'optimisation.
- Délai de présentation : réduisez le travail de rendu et de paint qui suit le traitement de l'événement. Sur les pages complexes avec un DOM volumineux, c'est souvent la phase la plus longue.
Pour des stratégies complémentaires transversales aux trois phases, consulte nos guides pour améliorer l'INP en évitant le défilement JavaScript et choisir entre le chargement async ou defer pour votre JavaScript.
Votre score Lighthouse ne dit pas tout.
Vos vrais utilisateurs sont sur Android en 4G. Moi, j'analyse ce qu'ils vivent réellement.
Analyser les données terrain
