INP : la note que votre site rate sans que vous le sachiez.

Trois mesures, prises chez vos visiteurs

Google évalue l'expérience de vos pages avec trois indicateurs, les Core Web Vitals :

• LCP, le temps que met le contenu principal à s'afficher. Bon en dessous de 2,5 secondes.
• INP, la réactivité de la page quand on clique. Bon en dessous de 200 millisecondes.
• CLS, la stabilité visuelle, ces éléments qui bougent pendant que vous lisez. Bon en dessous de 0,1.

Deux précisions changent tout. D'abord, ces valeurs sont mesurées chez de vrais visiteurs, dans Chrome, sur les 28 derniers jours, pas dans le test que vous venez de lancer. Ensuite, Google retient le 75ᵉ centile : il faut que trois visites sur quatre soient bonnes, pas la moyenne. Un site rapide pour vous en fibre à Aix peut être mauvais pour un client en 4G sur l'autoroute.

Dans PageSpeed Insights, ces vraies mesures apparaissent en haut, sous « données de terrain ». La note colorée sur cent, elle, vient d'un test simulé. C'est un indice, pas un verdict.

Autant appliquer la règle à moi-même : quand j'annonce un score Lighthouse sur mes offres, c'est un indice de construction saine, pas une preuve de ce que vivront vos visiteurs. La preuve, elle arrive après la mise en ligne, avec les données de terrain.

INP, celle que personne ne surveille

Les deux premières sont connues. La troisième est récente : l'INP a remplacé le FID le 12 mars 2024, et beaucoup de sites ne l'ont jamais regardée.

La différence entre les deux est instructive. Le FID ne mesurait que le délai avant que le navigateur commence à traiter votre premier clic. Une mesure indulgente : elle s'arrêtait au démarrage du traitement, et ne regardait qu'une seule interaction.

L'INP est autrement plus exigeant. Il observe toutes vos interactions, chaque clic, chaque appui, chaque frappe au clavier, et retient une valeur représentative du pire de ce que vit l'utilisateur. Et il mesure toute la chaîne : le délai, le traitement, puis l'affichage du résultat à l'écran. Autrement dit, le temps que met votre page à réagir.

Vos visiteurs ne mesurent pas votre vitesse d'affichage. Ils mesurent le silence entre leur clic et votre réponse.

Pourquoi cette mesure sanctionne les sites empilés

Quand quelqu'un clique, le navigateur doit exécuter le code JavaScript rattaché à cette action avant de pouvoir redessiner l'écran. Tant qu'il calcule, rien ne bouge. C'est ce blanc que mesure l'INP.

Or sur un site construit par accumulation, chaque brique ajoute son code. La bannière de cookies, le widget de discussion, le carrousel de la page d'accueil, l'outil de statistiques, la fenêtre d'inscription à la newsletter, l'extension qui affiche les avis. Aucune n'est coupable isolément. Ensemble, elles se disputent le même fil d'exécution, et c'est votre visiteur qui attend.

Le symptôme est facile à reconnaître, vous l'avez déjà vécu : vous tapez sur un menu mobile, il ne se passe rien, vous tapez une deuxième fois, et le menu s'ouvre puis se referme aussitôt.

Le test, en dix minutes

Ouvrez PageSpeed Insights et entrez l'adresse d'une page réelle. Pas votre page d'accueil, une page où les gens cliquent vraiment : contact, tarifs, prise de rendez-vous.

Regardez les données de terrain, tout en haut. Si elles sont absentes, votre page n'a pas assez de trafic pour que Chrome ait collecté des mesures. Passez alors par une page plus visitée, ou par la Search Console, qui agrège votre site entier.

Lisez les trois valeurs en mobile d'abord, c'est là que ça casse en premier. Et si l'INP dépasse 200 ms, ouvrez le code source de la page et comptez les scripts externes. Vous saurez immédiatement d'où vient le problème.

Si vous préférez une lecture d'ensemble, le scanner du site fait le tour en une passe, Core Web Vitals compris, et c'est gratuit.

Ce qu'on fait ensuite

La réponse honnête tient en trois niveaux, du plus simple au plus douloureux.

Supprimer d'abord. Faites l'inventaire de vos scripts et posez pour chacun la seule question qui vaille : qu'est-ce qui se casse si je l'enlève ? Le chat que personne n'utilise depuis huit mois, l'outil de statistiques en double, l'extension d'un service résilié. C'est le gain le moins cher du métier.

Différer ensuite. Ce qui reste n'a pas besoin de s'exécuter au chargement, une bannière de partage peut attendre que la page soit utilisable.

Reconstruire, en dernier recours. Parfois le problème ne vient pas des extensions mais du thème lui-même, et aucun réglage n'y changera rien. Là, il vaut mieux le dire franchement plutôt que de vendre trois mois d'optimisation qui ne donneront rien. C'est le seul cas où une refonte se justifie sur ce motif.

Le rapport avec un site sans CMS

C'est là que la question devient structurelle. Un site écrit à la main ne part pas avec un socle de code générique conçu pour tous les cas d'usage, chargé avant même votre contenu. Il n'exécute que ce que vous avez décidé d'exécuter. C'est le fond du sujet, et j'en ai fait un article entier.

Ce n'est pas de la magie, c'est de la soustraction : un bon INP ne s'obtient pas en ajoutant un outil d'optimisation, mais en n'ayant rien à ralentir.

Allez voir votre INP. C'est gratuit, ça prend dix minutes, et ça vous dira en une seule valeur ce que vos visiteurs ressentent sans jamais vous le dire.

Sources

• Interaction to Next Paint becomes a Core Web Vital on March 12, web.dev. Source primaire, annonce du remplacement du FID par l'INP le 12 mars 2024.
• Introducing INP to Core Web Vitals, blog Google Search Central. Source primaire.
• Interaction to Next Paint (INP), web.dev. Source primaire pour le seuil de 200 ms et le mode de calcul.
• Core Web Vitals, web.dev. Source primaire pour les trois seuils et le 75e centile.

Questions fréquentes

Qu'est-ce que l'INP, et depuis quand compte-t-il ?

L'INP, pour Interaction to Next Paint, mesure le temps entre une interaction du visiteur et le moment où la page affiche le résultat à l'écran. Il a remplacé le FID parmi les Core Web Vitals le 12 mars 2024. Le seuil considéré comme bon est de 200 millisecondes, mesuré au 75e centile chez de vrais visiteurs.

Pourquoi mon score PageSpeed est bon alors que mon INP est mauvais ?

Parce que ce sont deux choses différentes. La note colorée sur cent vient d'un test simulé lancé à l'instant. L'INP vient des données de terrain, collectées chez de vrais visiteurs dans Chrome sur les vingt-huit derniers jours. Un site rapide sur votre fibre peut être mauvais pour un client en 4G.

Comment améliorer un INP dans le rouge ?

En réduisant le code JavaScript qui s'exécute au moment du clic. Tant que le navigateur calcule, il ne peut pas redessiner l'écran, et c'est ce blanc que mesure l'INP. Concrètement : supprimer les scripts tiers devenus inutiles, différer ceux qui ne servent pas à l'affichage initial, et découper les traitements longs.

Sur le même sujet : les ressources tierces qui ralentissent une page, et le scanner gratuit.