Core Web Vitals comme signal : ce que change vraiment l’INP pour les développeurs

Pendant plusieurs années, le FID (First Input Delay) avait quelque chose de rassurant pour beaucoup de sites WordPress : il ne mesurait que le délai avant la toute première interaction de l’utilisateur, un moment généralement bref dans la vie d’une page. Beaucoup de sites obtenaient un score correct sans effort particulier, simplement parce que cette première interaction survenait souvent avant que le JavaScript le plus lourd n’ait fini de s’exécuter en arrière-plan.

Depuis mars 2024, l’INP (Interaction to Next Paint) a remplacé le FID dans les Core Web Vitals officiels de Google. Ce changement n’est pas une simple substitution de métrique : il déplace la fenêtre d’observation de la performance perçue, du tout premier instant de la page vers l’ensemble de la session de navigation.

Ce que l’INP mesure réellement

Contrairement au FID, qui ne s’intéressait qu’à la première interaction, l’INP observe toutes les interactions de l’utilisateur pendant qu’il reste sur la page (clics, appuis sur des touches, interactions tactiles), et retient la latence la plus représentative de l’ensemble de ces interactions. Un site peut donc avoir un excellent temps de réponse à la première interaction, et un INP dégradé si un menu qui s’ouvre au bout de la visite, ou un filtre de recherche activé plus tard, réagit lentement une fois que davantage de scripts se sont accumulés en mémoire.

Le seuil considéré comme bon par Google se situe sous 200 millisecondes, entre 200 et 500 millisecondes la performance est jugée à améliorer, et au-delà de 500 millisecondes elle est considérée comme mauvaise.

Pourquoi WordPress est particulièrement concerné

Un site WordPress accumule souvent, au fil du temps, des scripts issus de plusieurs sources indépendantes : extensions diverses, widgets tiers, scripts de suivi analytique, constructeurs de pages. Chacun pris isolément peut sembler léger, mais leur empilement sur une même page produit un thread principal du navigateur surchargé, ce qui allonge précisément le temps de réponse aux interactions ultérieures, exactement ce que l’INP mesure.

Le passage du FID à l’INP a ainsi révélé, sur beaucoup de sites WordPress à base d’extensions nombreuses, un problème de performance qui existait déjà mais que l’ancienne métrique ne captait tout simplement pas.

Les leviers techniques les plus efficaces

• Découper les tâches JavaScript longues avec setTimeout ou l’API scheduler.yield quand elle est disponible, pour laisser le thread principal respirer entre deux étapes de calcul.
• Charger en différé (defer) les scripts non indispensables au premier rendu, notamment ceux des extensions de widgets sociaux ou de chat en direct, rarement utiles dans la première seconde de visite.
• Auditer les gestionnaires d’événements ajoutés par les extensions actives, un menu ou un formulaire de recherche mal optimisé pouvant à lui seul dégrader tout le score INP d’un gabarit de page.
• Limiter les re-rendus inutiles sur les interfaces construites avec des blocs interactifs ou l’Interactivity API introduite en WordPress 6.5, qui peut, mal utilisée, provoquer des recalculs superflus à chaque interaction.

Mesurer avant d’optimiser

Contrairement au LCP ou au CLS, mesurables assez fidèlement en laboratoire, l’INP dépend fortement du comportement réel des utilisateurs (quelles interactions, à quel moment de la session), ce qui rend les données de terrain de la Search Console et du Chrome User Experience Report bien plus fiables qu’un test isolé en laboratoire pour ce signal précis.

// Suivre l'INP côté client avec la bibliothèque officielle web-vitals
import { onINP } from 'web-vitals';

onINP( ( metrique ) => {
    console.log( 'INP mesuré :', metrique.value );
    // Envoyer la valeur à un outil d'analyse pour un suivi dans le temps
} );

Un signal parmi d’autres, pas le seul

Il reste important de garder en tête que les Core Web Vitals, INP compris, constituent un signal de classement parmi de nombreux autres, avec un poids qui reste secondaire face à la pertinence du contenu lui-même. Un site avec un excellent INP mais un contenu médiocre ne dépassera pas dans les résultats de recherche un site au contenu très pertinent mais légèrement moins réactif. Ce point est régulièrement rappelé par Google lui-même, sans que le message soit toujours bien reçu par des équipes qui traitent parfois la performance comme un objectif en soi plutôt que comme un signal parmi d’autres.

L’INP a changé une chose concrètement pour moi : je ne teste plus seulement le chargement d’une page, je teste désormais son comportement après plusieurs interactions successives, en simulant une vraie session de navigation.

En résumé

Le remplacement du FID par l’INP en mars 2024 déplace l’attention technique du tout premier instant de chargement vers l’ensemble de la session de navigation, un changement particulièrement sensible sur des sites WordPress chargés en extensions et scripts tiers accumulés au fil du temps. Les leviers d’optimisation passent principalement par le découpage des tâches JavaScript longues et l’audit des gestionnaires d’événements des extensions actives, en gardant à l’esprit que ce signal reste secondaire face à la pertinence globale du contenu.