Trouver et corriger les problèmes d'Interaction to Next Paint (INP) : Guide étape par étape
Apprenez à identifier et corriger les problèmes d'Interaction to Next Paint en utilisant les données RUM, Chrome DevTools et 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ébutez avec l'INP, commencez par la page hub INP pour une vue d'ensemble complète.
Dans cet article, nous allons parcourir une méthodologie complète pour identifier les problèmes d'Interaction to Next Paint et expliquer ensuite comment les corriger. Le processus implique de confirmer le problème dans la Google Search Console, de diagnostiquer les causes profondes avec des données de Real User Monitoring (RUM), de répliquer les conditions localement et d'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 judicieux 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'effectuer des modifications de code, vérifiez le problème dans la Google Search Console afin de travailler à partir de données réelles (field data) plutôt que de suppositions.
Connectez-vous à votre Google Search Console. Dans le menu de gauche, cliquez sur Core Web Vitals et sélectionnez Mobile ou Bureau (conseil : la plupart du temps, les problèmes d'INP apparaissent d'abord sur mobile, commencez donc 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 confirmé l'existence d'un problème.
Étape 2 : Identifier les problèmes d'Interaction to Next Paint
Google Search Console ne vous donne aucune information à part des groupes d'URL pour comprendre ce qui cause les problèmes avec l'Interaction to Next Paint. La plupart du temps, les développeurs y vont donc à l'aveugle. Ils commencent par supprimer le JavaScript inutilisé (toujours une excellente idée) et décharger le thread principal (aussi une excellente idée), mais cela corrige rarement l'INP complètement.
C'est pourquoi, pour améliorer l'INP, nous avons besoin de savoir exactement ce qui se passe. Nous avons besoin de réponses à quatre questions critiques :
Quels éléments, lorsqu'on interagit avec eux, causent un mauvais score INP ?
Habituellement, un mauvais score INP n'est pas causé par un seul élément mais par une combinaison de problèmes. Nous devons
les aborder 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 seulement
sur quelques pages sélectionnées ?
Comment pouvons-nous répliquer
ces interactions ? Vous avez peut-être déjà découvert qu'il
est difficile de répliquer les problèmes d'INP. C'est pourquoi nous devons nous préparer au succès en
imitant les caractéristiques des appareils ayant un mauvais score INP.
Mettre en place 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 que cela peut représenter beaucoup
de travail supplémentaire.
Une bonne alternative à l'envoi de vos données Core Web Vitals à votre propre backend est d'utiliser l'un des nombreux outils RUM disponibles. Nous avons développé CoreDash spécifiquement pour ces cas d'utilisation. CoreDash est un outil RUM peu coûteux, rapide et efficace qui fait le travail. Bien sûr, il existe de nombreuses solutions RUM sur le marché et elles feront également l'affaire (bien qu'à un prix plus élevé).
Trouver les interactions lentes par élément qui causent un INP élevé
La première chose à faire est de 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 URL filtrées par état de chargement. Cela vous donnera plus d'informations sur la cause profonde 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 l'impact le plus élevé pour créer un autre filtre.
Trouver les URL responsables des scores INP élevés
Enfin, lorsque nous avons filtré les éléments avec l'interaction la plus lente et l'état de chargement correct, nous allons regarder les URL où l'INP est le pire. Dans ce cas, cela se produit clairement sur un ensemble spécifique de pages.
Trouver les caractéristiques des appareils
Une fois que nous avons identifié les interactions lentes, l'état de chargement et les URL qui causent une Interaction to Next Paint élevée, nous allons examiner quels types de visiteurs causent les pires scores INP. Nous regarderions la mémoire de l'appareil, 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 réplication et à la journalisation du problème.
Utilisation de l'API Long Animation Frames (LoAF) pour les diagnostics INP
L'API Long Animation Frames (LoAF) fournit des données d'attribution granulaires qui vous aident à identifier exactement quels scripts et fonctions sont responsables des interactions lentes. Contrairement à l'ancienne API Long Tasks, LoAF vous donne les URL de script, les noms de fonctions et la répartition du temps par frame. Cela en fait un outil inestimable pour le débogage de l'INP, surtout lorsqu'il est combiné avec des données RUM d'un outil comme CoreDash.
Utilisez le code suivant pour collecter les entrées LoAF pour les interactions qui dépassent un seuil. Cet observateur capture l'attribution du script, la durée et le temps de blocage pour chaque longue frame d'animation :
// Observe Long Animation Frames for INP attribution
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
// Only log frames longer than 50ms
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 du délai de présentation. Pour une discussion plus approfondie sur la façon dont le chargement JavaScript async vs defer affecte ces délais, consultez notre guide dédié.
Étape 3 : Répliquer et déboguer les interactions causant un score INP élevé
Une fois que nous avons toutes les informations dont nous avons besoin, nous pouvons commencer à creuser profondément dans les problèmes sous-jacents de l'Interaction to Next Paint.
Préparez-vous au succès : répliquez les circonstances d'échec de l'INP
La prochaine chose à faire est d'essayer de recréer l'échec INP. Nous faisons cela en imitant les circonstances où l'INP pourrait échouer.
Utilisez le panneau Performance de Chrome : Ouvrez les outils de développement 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 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 concurrence matérielle sur 4 ou 8 pour imiter votre appareil mobile moyen.
Pour charger Chrome avec moins de mémoire disponible (bien que baisser les réglages réseau et CPU fasse souvent l'affaire), démarrez Chrome dans un conteneur Docker et allouez moins de mémoire.
Recharger la page, interagir et vérifier l'INP avec le visualiseur Core Web Vitals
L'étape suivante pour trouver la cause des mauvais scores INP est de simuler les conditions et de confirmer
que les scores INP sont effectivement aussi mauvais que 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 pour lequel vous vous êtes préparé dans les étapes précédentes. Il est temps de découvrir pourquoi une certaine interaction cause le mauvais score d'Interaction to Next Paint.
Ouvrez la Console Développeur Chrome (Ctrl+Shift+I), naviguez vers le 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 timeline. Cherchez 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.
Lecture de la trace de performance
Dans le panneau Performance de Chrome, l'interaction apparaîtra comme une barre colorée dans la piste "Interactions". Cliquez dessus pour voir la durée totale de l'INP et sa répartition. En dessous, dans la piste "Main", vous pouvez voir les tâches individuelles qui se sont exécutées pendant l'interaction. Faites attention à :
- Tâches avant le gestionnaire d'événements : elles contribuent à l'input delay
- Le gestionnaire d'événements lui-même : c'est le processing time
- Travail de rendu après la fin du gestionnaire : c'est le presentation delay
Recoupez ces découvertes avec vos données LoAF pour confirmer que les scripts identifiés dans la trace correspondent aux données d'attribution de votre outil RUM. C'est aussi un bon moment pour vérifier si des gestionnaires de défilement JavaScript contribuent au problème.
Étape 4 : Corriger les problèmes d'INP
Nous sommes maintenant à un point où nous savons quelle interaction cause notre mauvais INP et nous avons analysé exactement ce qui se passe pendant cette interaction lente. Cela signifie qu'il est temps de commencer à corriger l'Interaction to Next Paint. L'Interaction to Next Paint peut être décomposée en 3 phases : input delay, processing time, et presentation delay.
Chaque phase de l'Interaction to Next Paint doit être traitée différemment. Ci-dessous se trouve un résumé des stratégies les plus impactantes pour chaque phase. Pour des guides d'optimisation complets, suivez les liens vers les pages dédiées.
Minimiser l'Input Delay :
L'Input delay est le temps entre l'interaction avec la page et le moment où le callback de l'événement commence à s'exécuter. Bien qu'il y ait toujours un certain input delay (même les navigateurs ont besoin de temps pour planifier les callbacks), il y a plusieurs choses à considérer :
- Évitez les tâches longues (long tasks). Chaque fois qu'une tâche s'exécute, elle bloque le thread principal et laisse les callbacks d'événements en attente. C'est particulièrement important lors de l'optimisation des clics précoces (puisque la plupart des scripts s'exécuteront à ce moment-là). Pour des stratégies pour réduire le blocage JavaScript, consultez notre guide sur JavaScript async vs defer.
- Soyez prudent lors de la création de nouvelles tâches. Par exemple, des tâches récurrentes via
setTimeout()ou des tâches qui se produiront probablement avant l'événement INP comme des callbacks sur l'événementmouseover. - Mesurez et évaluez 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 une mise à jour immédiate de la mise en page. Soit priorisez la fonctionnalité, soit cachez/désactivez l'élément avant qu'il ne fonctionne correctement.
- Utilisez des web workers pour exécuter du JavaScript hors du thread principal du navigateur. Les web workers permettent aux scripts de s'exécuter hors du thread principal. Cela empêchera le thread principal de bloquer et de causer des problèmes d'input delay INP.
- Chargez les scripts tiers non essentiels pendant le temps d'inactivité du navigateur. Certains scripts sont plus critiques que d'autres. Il est judicieux 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 14 méthodes pour différer le JavaScript pour des techniques pratiques.
Minimiser le Processing Time
- Supprimez le code inutile. Le code inutile est soit du code ancien qui s'exécute toujours, soit du nouveau code qui n'est pas nécessaire sur cette page spécifique mais qui prend tout de même 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 code critique qui doit s'exécuter avant l'INP et en code non critique (par exemple l'envoi d'analyses) et planifiez cela après l'événement paint avec la méthode
requestIdleCallback(). - Optimisez le code qui doit s'exécuter avant le paint. Vérifiez votre code et réécrivez les parties lentes ou inefficaces.
- Fournissez un retour immédiat. Sur les tâches compliquées ou potentiellement lentes, fournissez un retour immédiat avant d'exécuter le code principal.
Minimiser le Presentation Delay
- Gardez le DOM petit et simple. Il sera beaucoup plus facile pour un navigateur de rendre une page avec peu d'éléments DOM simples et non imbriqués (nœuds HTML) que de rendre une page avec de nombreux nœuds DOM imbriqués. En savoir plus sur la correction d'une taille de DOM excessive.
- Utilisez content-visibility pour le rendu différé 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 rendant ce contenu hors écran juste à temps.
Solution rapide : céder au thread principal avec scheduler.yield()
L'une des techniques les plus efficaces pour améliorer l'INP à travers les trois phases est de céder au thread principal entre le travail critique et le travail non critique. L'API scheduler.yield() fournit un moyen propre de le faire. Voici une fonction d'aide réutilisable avec une solution de repli 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);
});
}
// Usage in an event handler
async function handleButtonClick() {
// Critical work: update the UI
updateVisualFeedback();
// Yield to let the browser paint
await yieldToMain();
// Non-critical work: analytics, logging
sendAnalyticsEvent('button_click');
logInteraction();
}
Plongée en profondeur dans chaque phase de l'INP
Maintenant que vous savez comment identifier et corriger les problèmes d'INP, explorez chaque phase en détail :
- Input Delay : Apprenez à minimiser le temps entre l'interaction utilisateur et le début du traitement de l'événement. L'input delay représente environ 18% du temps total INP.
- Processing Time : Optimisez l'exécution du gestionnaire d'événements qui représente environ 40% du temps total INP.
- Presentation Delay : Réduisez le travail de rendu et de peinture qui représente environ 42% du temps total INP.
Pour des stratégies supplémentaires qui couvrent les trois phases, consultez nos guides sur l'amélioration de l'INP en abandonnant le défilement JavaScript et le choix entre async vs defer pour votre JavaScript.
I have done this before at your scale.
Complex platforms, large dev teams, legacy code. I join your team as a specialist, run the performance track, and hand it back in a state you can maintain.
Discuss Your Situation
