Parmi les trois Core Web Vitals, l’Interaction to Next Paint (INP) est celui qui résiste le plus. Autour de 43 % des sites échouent encore au seuil des 200 millisecondes, ce qui en fait le signal le plus souvent raté. Contrairement à son prédécesseur, l’INP juge la réactivité d’une page sur toute la durée de la visite, pas seulement au premier clic — un changement de méthode qui explique pourquoi tant d’interfaces jugées « fluides » passent au rouge.
Ce que mesure l’INP, et pourquoi il a remplacé le FID
Le First Input Delay ne mesurait que le délai avant la prise en compte de la première interaction, et ignorait tout le travail effectué ensuite. La plupart des sites obtenaient un « bon » FID sans que cela reflète l’expérience réelle. L’INP corrige ce biais : il observe la latence de toutes les interactions d’une visite — clics, appuis tactiles, frappes clavier — et retient une valeur proche de la pire. Une interface peut donc afficher un LCP et un CLS irréprochables tout en échouant sur l’INP.
Chaque interaction se décompose en trois phases, et l’INP les additionne : le délai d’entrée (le temps pendant lequel le fil principal est occupé avant de pouvoir traiter l’événement), le temps de traitement (l’exécution des gestionnaires d’événements), et le délai de présentation (le temps de calcul du style et de peinture de la frame suivante).
Les seuils à viser
Les seuils sont mesurés au 75e centile des interactions réelles, sur le 75e centile des appareils. Une valeur de laboratoire ne suffit pas à valider un site.
| Métrique | Bon | À améliorer | Mauvais |
|---|---|---|---|
| INP (réactivité) | ≤ 200 ms | 200 – 500 ms | > 500 ms |
| LCP (chargement) | ≤ 2,5 s | 2,5 – 4 s | > 4 s |
| CLS (stabilité) | ≤ 0,1 | 0,1 – 0,25 | > 0,25 |
L’INP ne se corrige pas en laboratoire : il se mesure sur le terrain, au 75e centile des interactions réelles.
Mesurer l’INP sur le terrain
La donnée qui compte est celle du terrain (field data), pas celle d’un audit synthétique. La bibliothèque web-vitals de l’équipe Chrome expose l’INP avec l’attribution de l’élément et de la phase responsables, ce qui transforme un chiffre abstrait en piste d’action. Ces valeurs peuvent être remontées vers l’outil analytique du site pour un suivi continu, comme le pilotage via GA4 et la Search Console.
import { onINP } from 'web-vitals/attribution';
onINP((metric) => {
const a = metric.attribution;
// Élément et phase responsables de la pire interaction
console.log('INP', metric.value, a.interactionTarget, {
inputDelay: a.inputDelay,
processingDuration: a.processingDuration,
presentationDelay: a.presentationDelay,
});
navigator.sendBeacon('/rum', JSON.stringify({ inp: metric.value }));
}, { reportAllChanges: false });La phase mise en cause oriente la correction : un inputDelay élevé pointe un fil principal saturé, un processingDuration long désigne un gestionnaire trop lourd, un presentationDelay important trahit un rendu coûteux.
Découper les tâches longues
La cause la plus fréquente d’un mauvais INP est une tâche longue qui monopolise le fil principal et retarde le traitement de l’interaction. La parade consiste à rendre la main au navigateur entre deux morceaux de travail. L’API scheduler.yield() permet ce découpage tout en reprenant la main en priorité, là où un setTimeout classique renvoie la tâche en fin de file.
async function handleClick() {
updateUIImmediately(); // retour visuel instantané
for (const chunk of workChunks) {
processChunk(chunk);
// Rend la main au navigateur pour traiter d'autres interactions
if ('scheduler' in window && 'yield' in scheduler) {
await scheduler.yield();
} else {
await new Promise((r) => setTimeout(r, 0));
}
}
}Trois autres leviers complètent le découpage : différer le travail non essentiel après la peinture avec requestIdleCallback, éviter le layout thrashing en séparant les lectures et les écritures du DOM, et alléger le coût de rendu en limitant la portée des recalculs de style. Réduire la quantité de JavaScript exécutée au démarrage — code splitting, hydratation différée — reste le levier de fond.
Repère. Un bon score dans Lighthouse ne garantit pas un bon INP. Lighthouse produit une donnée de laboratoire sur une seule interaction simulée ; l’INP officiel provient du terrain, agrégé sur 28 jours. Un site peut afficher 100 en performance dans Lighthouse et rester au rouge sur l’INP dans la Search Console.
Ce qu’il faut retenir
L’INP mesure la réactivité de toutes les interactions d’une visite, avec un objectif de 200 ms au 75e centile. Il se diagnostique avec des données de terrain et l’attribution de web-vitals, jamais sur un seul audit de laboratoire. Les gains viennent surtout du découpage des tâches longues et de la réduction du JavaScript exécuté sur le fil principal. C’est un chantier de fond, mais c’est aussi le Core Web Vital où l’effort se voit le plus vite dans les données réelles.
Sur les sites que j’audite, l’erreur la plus commune est de valider l’INP dans Lighthouse et de considérer le sujet clos. Le jour où l’on branche l’attribution de web-vitals sur le trafic réel, la vraie cause saute aux yeux — presque toujours un gros gestionnaire d’événement ou un script tiers qui bloque le fil principal. Je commence toujours par mesurer avant d’optimiser quoi que ce soit : sans donnée de terrain, on corrige à l’aveugle. — Simon Janvier
Pour aller plus loin : la documentation de référence « Interaction to Next Paint (INP) » sur web.dev détaille les phases d’une interaction et les techniques d’optimisation.
