Mesurer INP et améliorer la réactivité avec INP Scanner

Ce guide explique INP et l’utilisation d’INP Scanner Milten pour examiner les interactions lentes. INP a remplacé FID dans les Core Web Vitals en mars 2024. Un test en laboratoire couvre les actions exécutées, pas l’expérience de tous les visiteurs.

Qu’est-ce qu’Interaction to Next Paint (INP) ?

INP évalue la réactivité aux clics, aux pressions tactiles et aux saisies au clavier pendant une visite. La latence comprend l’attente avant le traitement de l’entrée, l’exécution des gestionnaires et l’attente du prochain affichage. FID mesurait seulement le délai de la première entrée ; INP considère les interactions admissibles sur l’ensemble de la visite. Il ne mesure pas la durée complète d’une réponse réseau asynchrone ultérieure.

Principales caractéristiques de l'INP :

• Agrégation : INP n’est pas une moyenne. Il correspond généralement à l’interaction la plus lente, avec exclusion de valeurs aberrantes lors des visites comportant beaucoup d’interactions.
• Seuils : bon jusqu’à 200 ms ; à améliorer au-delà de 200 ms et jusqu’à 500 ms ; mauvais au-delà de 500 ms. Pour les visites réelles, utilisez le 75e centile, séparément sur mobile et ordinateur.
• Actions incluses : clics, pressions tactiles et clavier. Le défilement et le survol ne constituent pas eux-mêmes des interactions INP.

Pourquoi l'INP est-il important pour vous ?

1. Expérience utilisateur (UX)

Un retour visuel lent peut donner l’impression qu’un bouton ne fonctionne pas et provoquer des clics répétés. Mesurez l’interaction et son résultat. Les statistiques de chargement ne prouvent pas un effet d’INP sur le taux de rebond de votre site.

2. Classements SEO et recherche

INP fait partie des Core Web Vitals utilisés par les systèmes de classement de Google. Un bon score ne garantit pas une meilleure position, et un mauvais score ne prouve pas une pénalité fixe. Évaluez la réactivité avec la pertinence du contenu et les autres aspects de l’expérience de page.

3. La vitesse comme avantage concurrentiel

Un retour visuel rapide confirme que l’action a été reçue. Comparez les tâches importantes pour votre public : un même délai n’a pas le même effet dans tous les usages.

Utiliser INP Scanner de Milten

INP Scanner aide à examiner la réactivité dans un navigateur contrôlé. Vérifiez les actions exécutées et les limites du rapport avant de généraliser les résultats.

1. Vérifiez les interactions testées

Choisissez un parcours représentatif et confirmez les actions effectuées :

• Clics sur les boutons et les liens.
• Saisie au clavier dans les champs utiles.
• Défilement pour atteindre un élément ; le défilement lui-même n’est pas une interaction INP.

Un test contrôlé est un scénario reproductible, pas une mesure sur les appareils de tous les visiteurs. Notez le navigateur, le profil d’appareil et les conditions effectives du test. Complétez les parcours importants non couverts par des tests manuels.

2. Interprétez les durées

La mesure d’INP utilise Event Timing. PerformanceObserver peut observer les entrées event prises en charge ; il n’existe pas de type général render pour cet usage. Une bibliothèque comme web-vitals regroupe les interactions et calcule INP.

• Distinguez le délai d’entrée, l’exécution des gestionnaires et le délai de présentation.
• Recherchez les tâches JavaScript longues sur le thread principal.
• Examinez la fluidité des animations comme une question liée, mais distincte.

3. Examinez les observations

Utilisez les éléments réellement présents dans le rapport :

• Repérez les interactions enregistrées et leurs éléments cibles.
• Examinez une action lente, par exemple un bouton « Acheter » fictif prenant 600 ms ; ce chiffre n’est pas une mesure client.
• Vérifiez la cause supposée dans une trace de performance du navigateur et testez une modification ciblée.

Limites d’un test automatique

• Consultez les conditions actuelles du service et les champs du rapport.
• Un test dans un navigateur ne prouve pas que des appareils physiques de visiteurs ont été utilisés.
• Les actions non exécutées et les données absentes restent non vérifiées. Ajoutez des données réelles lorsqu’elles sont disponibles.

Causes fréquentes d’interactions lentes

1. Gestionnaires d'événements longs

Exemple pédagogique ; les fonctions et les données doivent être définies dans l’application :

button.addEventListener('click', () => {
	// Synchronous processing of 10,000 data rows
	const result = heavyCalculation(data)
	updateUI(result)
})

Problème : le calcul synchrone heavyCalculation occupe le thread principal et peut retarder le prochain affichage. Solution : réduisez ou découpez ce travail, ou déplacez les calculs adaptés dans un Web Worker. Un simple setTimeout ne fait que planifier la même tâche lourde plus tard, sans la sortir du thread principal.

2. CSS/JS bloquant le rendu

Exemple :

<link rel="stylesheet" href="large-styles.css" />
<script src="analytics.js" defer></script>

Problème : une feuille de style bloquante et des scripts coûteux peuvent retarder l’affichage ou le traitement des entrées. defer modifie la planification, sans supprimer le travail. La feuille de l’exemple s’applique à l’écran ; avec seulement media="print", ces styles ne s’appliqueraient pas à l’écran. Améliorations possibles :

• Intégrez uniquement le CSS vraiment critique et mesurez le compromis.
• Supprimez les styles inutilisés après vérification des classes dynamiques et des états de l’interface ; PurgeCSS doit être configuré correctement.
• Différez les scripts non critiques et réduisez leur coût d’exécution.

3. Animations lentes

Exemple :

@keyframes fade {
	from {
		opacity: 0;
		transform: translateX(-100px);
	}
	to {
		opacity: 1;
		transform: translateX(0);
	}
}

Problème : les animations de opacity et transform sont souvent efficaces, mais trop d’éléments animés simultanément peuvent provoquer des saccades. Améliorations possibles :

• Simplifiez les animations et limitez les éléments animés en même temps.
• Envisagez will-change: transform seulement si nécessaire, peu avant le changement. C’est une indication, pas une garantie d’accélération GPU ; un usage excessif consomme des ressources. Mesurez le résultat.

4. Recalculs forcés répétés de la mise en page (layout thrashing)

Exemple :

for (let i = 0; i < 100; i++) {
	element.style.height = `${i}px`
	console.log(element.offsetHeight) // Forces layout recalculation
}

Problème : alterner écriture de styles et lecture de géométrie, comme offsetHeight, peut forcer des recalculs répétés. Le calcul de la mise en page diffère de la peinture. Solution :

• Regroupez les lectures de géométrie avant les écritures lorsque c’est possible.
• Planifiez les changements visuels avec requestAnimationFrame si cela convient, mais n’y déplacez pas la même boucle de lectures et d’écritures en espérant supprimer le problème.

Comment améliorer l'INP : 5 conseils pratiques

1. Optimiser les gestionnaires d'événements

• Découpez les tâches longues et rendez la main au navigateur entre les morceaux, avec un mécanisme adapté tel que setTimeout.
• queueMicrotask ne laisse pas au navigateur l’occasion d’afficher une image : une chaîne de microtâches peut continuer à bloquer la page.
• Limitez le travail immédiat du gestionnaire et affichez rapidement un retour.

2. Réduire la taille du bundle JavaScript

• Supprimez les bibliothèques inutilisées (par exemple, en utilisant Webpack Bundle Analyzer).
• Appliquez le fractionnement du code pour charger les modules de manière dynamique.

3. Utilisez debounce et throttle

Limitez la fréquence des traitements coûteux si la tâche le permet. L’exemple suppose que debounce est défini ou importé. Gardez le retour visuel du champ immédiat : les 300 ms illustrent un choix de planification, pas un objectif INP.

const debouncedSearch = debounce((query) => {
	fetchResults(query)
}, 300)

4. Optimiser le rendu

• Réduisez la complexité inutile du DOM.
• Mesurez le coût des styles et de la mise en page sans accuser les sélecteurs à l’avance.
• Envisagez content-visibility: auto pour les sections hors écran et vérifiez la mise en page, le focus et l’accessibilité.

5. Test sur des appareils bas de gamme

Testez si possible des appareils modestes représentatifs. Les outils du navigateur peuvent simuler un processeur et un réseau plus lents, par exemple un ralentissement CPU de 4× et une connexion mobile limitée. Ce sont des conditions illustratives, pas un profil 3G fixe du service ni des tests sur appareils physiques.

Vérifiez le résultat

Répétez l’interaction après publication, dans des conditions comparables. Contrôlez le délai et le résultat fonctionnel : un panier plus réactif doit toujours contenir le bon article.

Utilisez INP Scanner de Milten dans cette démarche :

• Notez les actions testées et les données manquantes.
• Comparez le même parcours avant et après la correction.
• Évaluez les visites réelles avec leurs données : un bon résultat en laboratoire ne prouve pas un bon INP pour tous les utilisateurs.

Choisissez une interaction importante, identifiez une cause possible et testez une correction limitée. Distinguez les contrôles réussis, échoués et non exécutés.

Consultez le guide de mesure d’INP et le guide d’optimisation d’INP.