Comment corriger l'INP : Guide d'optimisation de l'Interaction to Next Paint

La réponse, c'est probablement l'INP

L'Interaction to Next Paint est officiellement devenu un Core Web Vital en mars 2024, remplaçant le First Input Delay (FID). Contrairement à son prédécesseur, l'INP ne mesure pas seulement la réactivité de votre page au chargement initial. Il suit la réactivité tout au long de la session utilisateur, exposant des problèmes que le FID manquait commodément. Comprendre les Core Web Vitals INP est essentiel pour maintenir vos classements de recherche.

Ce guide couvre ce que l'INP mesure, pourquoi tant de sites ont soudainement échoué après le changement, et des approches pratiques pour corriger les problèmes de réactivité dans les applications JavaScript. Vous apprendrez des techniques d'optimisation INP qui peuvent vous aider à améliorer votre score INP.

Prérequis

Avant de travailler sur les améliorations INP, vous devriez avoir :

• Une familiarité de base avec le panneau Performance de Chrome DevTools
• Une compréhension de la boucle d'événements JavaScript et du blocage du fil principal
• Accès à PageSpeed Insights ou Google Search Console pour votre site
• Connaissance du framework JavaScript de votre site (React, Vue, Next.js, etc.)

Si votre site a du trafic réel, vous aurez aussi besoin d'accéder aux données du Chrome UX Report (CrUX) via PageSpeed Insights ou Search Console pour voir les mesures terrain réelles.

Ce que l'INP mesure réellement

L'INP capture la latence complète des interactions utilisateur, du moment où quelqu'un clique, tape ou utilise son clavier jusqu'à ce que le navigateur affiche la prochaine image visuelle. Cela inclut tout ce qui se passe entre l'entrée et la réponse visible.

Les seuils sont simples :

• Bon : ≤ 200ms
• À améliorer : 200–500ms
• Mauvais : > 500ms

Pour passer les Core Web Vitals en matière de réactivité, vous devez avoir la plupart des interactions utilisateur réelles sous 200ms au 75e percentile. Cette fenêtre de 200ms semble généreuse jusqu'à ce que vous réalisiez à quelle vitesse les frameworks JavaScript peuvent la consommer.

Pourquoi cette métrique existe

Google a introduit l'INP parce que le FID créait un faux sentiment de sécurité. Environ 93% des sites avaient de bons scores FID sur mobile. Ce nombre est tombé à environ 65% avec l'INP.

L'écart existe parce que le FID ne mesurait que le délai d'entrée pour la première interaction, indiquant principalement si votre page était prête au chargement initial. L'INP capture la lenteur qui survient pendant l'utilisation réelle : quand l'hydratation se déclenche, quand des gestionnaires d'événements lourds s'exécutent, quand React re-rend des arbres de composants entiers.

Comment l'INP diffère du FID

Comprendre la différence entre INP et FID est crucial pour saisir pourquoi les scores ont changé. Les différences expliquent pourquoi votre site auparavant « rapide » pourrait maintenant montrer des problèmes de réactivité :

• Portée : Le FID mesurait uniquement la première interaction; l'INP mesure toutes les interactions durant la session
• Mesure : Le FID mesurait uniquement le délai d'entrée; l'INP mesure la latence complète de l'interaction
• Seuil : Le FID était à 100ms; l'INP est à 200ms
• Ce qu'il détecte : Le FID détectait la réactivité au démarrage; l'INP détecte la réactivité de toute la session

Le FID mesurait uniquement combien de temps le navigateur attendait avant de pouvoir commencer à traiter votre premier clic. L'INP mesure le délai d'entrée plus le temps de traitement plus le temps nécessaire pour afficher le résultat. Il fait cela pour chaque interaction qualifiante durant votre visite, puis rapporte approximativement la pire.

Le calcul inclut une suppression des valeurs aberrantes. Pour les pages avec beaucoup d'interactions, Google ignore une interaction à haute latence pour chaque 50 interactions afin d'empêcher les anomalies aléatoires de dominer le score.

Les trois phases de l'INP

Chaque interaction se décompose en trois phases, et des problèmes dans n'importe quelle phase nuisent à votre score :

Phase 1 : Délai d'entrée

C'est le temps passé à attendre que les gestionnaires d'événements démarrent. L'utilisateur a cliqué, mais le navigateur ne peut pas encore commencer le traitement parce que le fil principal est occupé avec autre chose. Apprendre à réduire le délai d'entrée est clé pour l'optimisation INP.

Causes courantes :

• Tâches longues s'exécutant pendant le démarrage de la page ou l'hydratation du framework
• Évaluation de scripts bloquant le fil principal
• Travail synchrone lourd provenant de scripts tiers

Phase 2 : Temps de traitement

C'est le temps passé à exécuter réellement vos gestionnaires d'événements. Le navigateur a commencé à traiter le clic, mais votre code prend du temps à terminer. L'optimisation des performances JavaScript est critique ici.

Causes courantes :

• Grands gestionnaires d'événements synchrones faisant trop de travail
• Mises à jour d'état coûteuses déclenchant des calculs
• Chemins de rendu inefficaces du framework

Phase 3 : Délai de présentation

C'est le temps dont le navigateur a besoin pour afficher le résultat visuel. Votre code a terminé, mais peindre la mise à jour prend plus longtemps que prévu.

Causes courantes :

• Grands arbres DOM (plus de 1 400 éléments devient problématique)
• CSS complexe nécessitant un recalcul de style lourd
• Re-rendus de composants lourds mettant à jour de grandes portions de la page

Notre expérience montre que la plupart des échecs INP proviennent des phases 1 et 2, particulièrement quand les frameworks JavaScript mettent en file d'attente du travail qui bloque le fil principal exactement quand les utilisateurs veulent interagir.

Quels sites ont le plus de difficultés

Le passage à l'INP a particulièrement touché certains types de sites :

Les applications monopage avec beaucoup de JavaScript côté client échouent souvent parce que l'hydratation et les transitions de routes bloquent le fil principal exactement aux moments où les utilisateurs veulent interagir. La performance d'hydratation React est un coupable fréquent.

Les sites de commerce en ligne avec des interfaces produits complexes, des systèmes de filtrage et des mises à jour de panier dynamiques dépassent fréquemment le seuil de 200ms quand les utilisateurs cliquent sur les options.

Les frontends legacy accumulant des années de JavaScript sans audit de performance ont tendance à avoir du code bloquant le fil principal dispersé partout.

Les sites chargés de scripts tiers comme les analytiques, publicités, widgets de clavardage et pixels de suivi voient souvent les délais d'entrée grimper parce que ces scripts se disputent le temps du fil principal.

Approches pratiques d'amélioration

Améliorer l'INP nécessite de traiter la phase qui cause le plus de délai. Commencez par profiler les interactions réelles dans DevTools pour identifier vos goulots d'étranglement spécifiques. Ces stratégies aideront à améliorer la réactivité du site web.

1. Fragmenter les tâches longues

Les tâches JavaScript longues (plus de 50ms) bloquent le fil principal et gonflent le délai d'entrée. Fragmentez-les en morceaux plus petits en utilisant scheduler.yield() (disponible dans Chrome 125 ) ou setTimeout. Utiliser scheduler.yield en JavaScript est l'approche moderne :

// Instead of processing everything at once async function processLargeDataset(items) {  for (const item of items) {    processItem(item);        // Yield to the main thread periodically    if (shouldYield()) {      await scheduler.yield();    }  } } // Fallback for browsers without scheduler.yield() function yieldToMain() {  return new Promise(resolve => setTimeout(resolve, 0)); }

2. Différer le travail non critique

Utilisez requestIdleCallback pour le travail qui n'a pas besoin d'être fait immédiatement :

// Schedule non-urgent updates for idle time function scheduleAnalyticsUpdate(data) {  if ('requestIdleCallback' in window) {    requestIdleCallback(() => {      sendAnalytics(data);    }, { timeout: 2000 });  } else {    setTimeout(() => sendAnalytics(data), 100);  } }

3. Utiliser debounce et throttle sur les gestionnaires d'événements

Pour les interactions qui se déclenchent rapidement (scroll, resize, changements d'input), limitez la fréquence d'exécution de vos gestionnaires :

function debounce(func, wait) {  let timeout;  return function executedFunction(...args) {    clearTimeout(timeout);    timeout = setTimeout(() => func.apply(this, args), wait);  }; } // Apply to search input const searchInput = document.getElementById('search'); searchInput.addEventListener('input', debounce((e) => {  performSearch(e.target.value); }, 300));

4. Réduire la taille et la complexité du DOM

Les grands DOM ralentissent les phases de traitement et de présentation. Travailler avec des équipes nous a appris que le nettoyage du DOM offre souvent les améliorations INP les plus notables :

• Virtualisez les longues listes au lieu de rendre tous les éléments
• Retirez les éléments cachés du DOM plutôt que d'utiliser display: none
• Simplifiez les structures imbriquées quand c'est possible
• Chargez le contenu paresseusement à mesure que les utilisateurs défilent

5. Adresser les problèmes spécifiques aux frameworks

React, Vue et autres frameworks ont leurs propres considérations INP :

React : Utilisez useMemo et useCallback pour éviter les re-rendus inutiles. Considérez React.lazy pour le code splitting et startTransition pour les mises à jour d'état non urgentes.

Vue : Exploitez correctement les propriétés computed et évitez les dépendances réactives qui déclenchent des mises à jour en cascade.

Next.js/Nuxt : Les deux frameworks ont sorti des mises à jour axées sur l'INP en 2024. Mettez à jour vers les versions récentes et suivez leurs recommandations d'hydratation pour réduire le blocage au démarrage.

Erreurs courantes à éviter

Se fier uniquement aux tests en laboratoire. L'INP peut sembler correct dans DevTools mais échouer sur le terrain parce que les vrais utilisateurs interagissent à des moments imprévisibles où le fil principal pourrait être occupé. Vérifiez toujours les données terrain du CrUX.

Ignorer les scripts tiers. Ce widget de clavardage ou cette bibliothèque d'analytiques pourrait être responsable d'un blocage significatif du fil principal. Auditez l'impact des tiers en utilisant le panneau Performance de Chrome DevTools.

Supposer qu'un chargement initial rapide signifie des interactions rapides. C'est exactement pourquoi le FID donnait des résultats trompeurs. Un site peut se charger rapidement mais devenir lent une fois que les frameworks JavaScript commencent à travailler.

Sur-optimiser pour les interactions rares. Concentrez-vous sur les interactions que les utilisateurs effectuent le plus souvent. L'INP rapporte approximativement la pire interaction, mais corriger vos chemins d'interaction les plus courants améliorera plus efficacement l'expérience utilisateur globale.

Différer trop agressivement. Déplacer tout le travail vers les idle callbacks peut rendre l'interface non réactive d'une autre manière. Trouvez l'équilibre entre le retour immédiat et le traitement en arrière-plan.

Mesurer et vérifier l'INP

PageSpeed Insights

Les données INP de PageSpeed Insights montrent les mesures en laboratoire et sur le terrain. Les données terrain proviennent du Chrome UX Report et reflètent les 28 derniers jours de mesures d'utilisateurs réels. C'est ce que Google utilise réellement pour le scoring Core Web Vitals.

Notez que les données terrain nécessitent suffisamment de trafic. Si votre page n'a pas assez de visites, vous ne verrez que les mesures en laboratoire, qui pourraient ne pas refléter l'INP réel.

Chrome DevTools

Le panneau Performance vous permet d'enregistrer les interactions et de voir exactement où le temps passe :

• Ouvrez DevTools et allez à l'onglet Performance
• Cliquez sur Record
• Effectuez l'interaction que vous voulez mesurer
• Arrêtez l'enregistrement
• Cherchez les entrées « Interaction » dans la timeline

Cela vous montre la répartition entre délai d'entrée, traitement et présentation pour des interactions spécifiques.

Google Search Console

Search Console a élargi le reporting INP fin 2024. Consultez le rapport Core Web Vitals pour voir quels groupes d'URL ont des problèmes INP et suivre les améliorations dans le temps.

Bibliothèque JavaScript Web Vitals

Pour un monitoring personnalisé, la bibliothèque web vitals de Google capture l'INP sur le terrain :

import { onINP } from 'web-vitals'; onINP((metric) => {  console.log('INP:', metric.value);  // Send to your analytics });

Mises en garde importantes sur les mesures

L'INP peut être absent pour les pages vues où les utilisateurs n'effectuent aucune interaction qualifiante. Cela peut compliquer l'analyse pour les pages où les utilisateurs lisent principalement du contenu sans cliquer.

L'Event Timing API qui alimente la mesure INP peut générer des entrées même quand il n'y a pas de véritables écouteurs d'événements. Lors de la construction d'un monitoring personnalisé, filtrez pour les interactions significatives plutôt que les données brutes d'event timing.

Conclusion

L'INP a relevé la barre de la réactivité web en mesurant ce que le FID ignorait : comment les sites se comportent durant l'utilisation réelle, pas seulement au premier clic. Les environ 28% de sites qui passaient le FID mais échouaient l'INP représentent une vraie frustration utilisateur qui était auparavant invisible aux Core Web Vitals.

Corriger l'INP signifie typiquement fragmenter les longues tâches JavaScript, gérer soigneusement l'hydratation des frameworks, garder des tailles de DOM raisonnables et auditer l'impact des scripts tiers. L'approche spécifique dépend de votre stack et de l'emplacement de vos goulots d'étranglement particuliers.

Nous avons constaté que les améliorations INP nécessitent souvent une expertise en profilage JavaScript et parfois des changements architecturaux, particulièrement pour les applications legacy avec une dette de performance accumulée. Si votre site a des difficultés avec les scores INP et que vous ne savez pas par où commencer, nous pouvons vous aider à identifier les goulots d'étranglement spécifiques et à construire un plan priorisé d'amélioration.