L'INP remplace le FID : pourquoi vos sites au vert passent au rouge

Pourquoi le FID était une métrique complaisante

Le FID mesurait le délai entre la première interaction de l'utilisateur et le moment où le navigateur commençait à la traiter. Deux limites majeures le rendaient peu représentatif.

Il ne mesurait que la première interaction. Tout ce qui se passait ensuite, pendant les minutes de navigation réelle, échappait à la mesure.

Il ne mesurait par ailleurs que le délai avant le début du traitement, en ignorant le traitement lui-même et l'affichage du résultat. Un bouton réagissant immédiatement mais mettant deux secondes à produire un effet visible obtenait un excellent score.

Résultat : la quasi-totalité des sites passaient. Une métrique que tout le monde réussit finit par ne plus mesurer grand-chose.

Ce que l'INP mesure réellement

L'INP observe toutes les interactions de la visite, clics, touchers et saisies clavier, et retient parmi les plus lentes une valeur représentative. Pour chacune, il mesure le cycle complet : le délai avant traitement, la durée du traitement, et le temps nécessaire pour afficher la mise à jour à l'écran.

Il s'agit donc d'une mesure de la réactivité perçue pendant toute la session. Le seuil est fixé à 200 millisecondes pour être considéré comme bon, 500 pour rester acceptable.

Cette exigence explique les basculements observés. Un site chargé de scripts tiers, de solutions de mesure et de balises publicitaires occupe le fil principal du navigateur en permanence. Le FID ne le voyait pas, l'INP le voit.

Les trois causes que je rencontre le plus

Les scripts tiers, de loin la première. Chaque outil de mesure, chaque module de discussion, chaque solution de test A/B consomme du temps de calcul sur le fil principal. Le plus efficace consiste souvent à en supprimer plutôt qu'à les optimiser.

Les gestionnaires d'événements trop lourds ensuite. Un clic qui déclenche un recalcul de mise en page complet coûte cher. La bonne pratique consiste à afficher immédiatement un retour visuel, puis à effectuer le travail lourd ensuite, en cédant la main au navigateur entre les étapes.

Les grandes structures de page enfin. Sur les applications à composants, chaque interaction peut provoquer un nouveau rendu d'une portion importante de l'interface. Les corrections y deviennent les plus coûteuses, car elles touchent l'architecture.

Ce que je ferais dans cet ordre

Commencez par les données de terrain, plutôt que par les tests de laboratoire. Le rapport d'expérience utilisateur dans la Search Console donne l'INP réel de vos visiteurs, avec leurs appareils et leurs connexions. Un test effectué depuis un ordinateur puissant sur une fibre ne révèle rien.

Identifiez ensuite les gabarits en cause plutôt que les pages. Le problème est presque toujours structurel, et corriger un gabarit corrige des milliers de pages.

Mesurez enfin le poids réel de chaque script tiers avant de discuter avec les équipes qui les ont demandés. La conversation devient bien plus simple avec un chiffre qu'avec une intuition.

Un dernier mot sur l'enjeu réel : le poids des signaux d'expérience dans le classement reste modeste, et je déconseille d'engager une refonte pour cette seule raison. L'effet de la réactivité sur le taux de conversion, en revanche, se mesure directement. C'est le bon argument.