Depuis le 12 mars 2024, l'INP (Interaction to Next Paint) a remplacé le FID parmi les Core Web Vitals de Google. Cette métrique est plus exigeante : elle ne mesure plus seulement le délai avant le traitement du premier clic, mais le temps de réponse de toutes les interactions pendant la visite. Beaucoup de sites qui affichaient un FID parfait se sont retrouvés en orange du jour au lendemain. Voici comment comprendre l'INP et l'améliorer.
Ce que mesure exactement l'INP
À chaque clic, appui sur l'écran ou frappe au clavier, le navigateur enchaîne trois phases :
- Le délai d'entrée : le temps d'attente avant que le gestionnaire d'événement puisse s'exécuter, souvent parce que le fil principal est occupé par un autre script ;
- Le temps de traitement : l'exécution de vos gestionnaires d'événements JavaScript ;
- Le délai de présentation : le calcul des styles, la mise en page et l'affichage de l'image suivante.
L'INP retient, en simplifiant, l'interaction la plus lente de la visite (en écartant les valeurs extrêmes sur les pages très interactives). Les seuils définis par Google, détaillés sur web.dev, sont les suivants :
| INP | Appréciation |
|---|---|
| 200 ms ou moins | Bon |
| Entre 200 et 500 ms | À améliorer |
| Plus de 500 ms | Mauvais |
Mesurer l'INP sur votre site
Les données de terrain d'abord
L'INP dépend des interactions réelles : un test de laboratoire ne clique sur rien et ne peut donc pas le mesurer. Les sources fiables sont :
- Google Search Console, rapport « Signaux Web essentiels », qui regroupe les URL par statut ;
- PageSpeed Insights, qui affiche les données du rapport CrUX de Chrome lorsque le site a assez de trafic ;
- La bibliothèque
web-vitals, qui permet d'envoyer l'INP de chaque visite vers votre outil de statistiques.
import { onINP } from 'web-vitals/attribution';
onINP(({ value, attribution }) => {
navigator.sendBeacon('/stats/inp', JSON.stringify({
value: Math.round(value),
target: attribution.interactionTarget,
type: attribution.interactionType,
}));
});
La version attribution indique l'élément concerné : vous savez immédiatement si le problème vient du menu, d'un filtre ou du bouton d'ajout au panier.
Reproduire en laboratoire
Une fois l'interaction lente identifiée, reproduisez-la dans l'onglet Performance des DevTools de Chrome, en activant le ralentissement du processeur (×4 ou ×6) pour simuler un smartphone moyen. Les tâches de plus de 50 ms apparaissent avec un triangle rouge : ce sont elles qu'il faut découper.
Les causes les plus fréquentes d'un mauvais INP
D'après mes audits, on retrouve presque toujours les mêmes coupables :
- Des scripts tiers trop lourds : chat en ligne, outils publicitaires, tests A/B, gestionnaires de balises ;
- Des gestionnaires d'événements qui font tout d'un coup : mise à jour de l'interface, calculs, envoi de statistiques et appel réseau dans la même fonction ;
- Un DOM trop volumineux : au-delà de quelques milliers de nœuds, chaque changement déclenche des recalculs de styles coûteux ;
- Des écouteurs
scrollouinputnon limités, qui saturent le fil principal.
Les techniques pour améliorer l'INP
Afficher d'abord, calculer ensuite
L'utilisateur doit voir une réaction immédiate. Mettez à jour l'interface en premier, puis cédez la main au navigateur avant le travail secondaire :
button.addEventListener('click', async () => {
button.classList.add('is-loading'); // retour visuel immédiat
await yieldToMain(); // laisse le navigateur afficher
applyFilters(); // travail plus lourd
sendAnalytics('filter_applied');
});
function yieldToMain() {
if ('scheduler' in window && 'yield' in scheduler) {
return scheduler.yield();
}
return new Promise(resolve => setTimeout(resolve, 0));
}
scheduler.yield() est disponible dans Chrome depuis la version 129 ; le repli sur setTimeout garantit le fonctionnement ailleurs.
Découper les longues tâches
Une boucle qui traite 2 000 éléments en une fois bloque le fil principal. Traitez-les par lots en rendant la main entre chaque lot avec la même fonction yieldToMain(). L'interface reste réactive même si le traitement total dure un peu plus longtemps.
Alléger le rendu
- Réduisez la taille du DOM : pagination, chargement à la demande, suppression des éléments masqués inutiles ;
- Utilisez
content-visibility: autosur les sections situées sous la ligne de flottaison, pour que le navigateur ne calcule pas leur rendu tant qu'elles ne sont pas visibles ; - Évitez de lire une dimension (
offsetHeight) juste après avoir modifié le style : cela force une mise en page synchrone.
Faire le ménage dans les scripts tiers
Chaque script tiers doit justifier sa présence. Chargez-les avec defer, retardez ceux qui ne servent pas immédiatement (le chat peut attendre la première interaction) et supprimez ceux que plus personne ne consulte. Pour les statistiques, une solution légère comme Matomo bien configuré pèse bien moins qu'un empilement d'outils marketing.
Mon approche sur les sites que je développe
Sur mes projets, je limite le JavaScript au strict nécessaire : rendu côté serveur, interactions légères et aucun framework lourd quand une page n'en a pas besoin. C'est ce qui permet d'obtenir un INP bien inférieur à 200 ms, y compris sur mobile, et d'atteindre un score Lighthouse de 100. Si votre rapport Search Console signale des problèmes d'INP, je peux réaliser un audit de performance et vous indiquer les corrections prioritaires.