« Interaction to Next Paint replaces First Input Delay as a Core Web Vital metric » : c’est la formulation retenue par Google dans sa documentation officielle sur web.dev pour acter, en mars 2024, le remplacement du FID par l’INP au sein des trois Core Web Vitals. Le changement était annoncé depuis mai 2022, mais son entrée en vigueur effective change concrètement ce qu’un développeur WordPress doit surveiller pour éviter une alerte dans le rapport Search Console.
La différence n’est pas cosmétique. Le FID ne mesurait que le délai avant que le navigateur commence à traiter la toute première interaction de l’utilisateur, souvent un clic anodin sans conséquence visible. L’INP, lui, évalue la réactivité de la page sur l’ensemble de sa durée de vie, en retenant l’interaction la plus lente rencontrée par le visiteur. Un site pouvait afficher un excellent FID tout en restant poussif sur les interactions suivantes ; ce n’est plus possible de le masquer avec l’INP.
Ce que mesure réellement l’INP
L’INP capture le temps écoulé entre l’action de l’utilisateur — clic, tape sur un écran tactile, appui sur une touche — et le prochain rendu visuel qui en résulte à l’écran, en tenant compte du temps de traitement de l’événement, d’éventuels délais de mise en file d’attente si le thread principal est occupé, et du temps de présentation du rendu. Le seuil « bon » retenu par Google est fixé à 200 millisecondes, contre 500 millisecondes pour un seuil « à améliorer ».
Sur un site WordPress classique, l’essentiel du risque ne vient pas du thème lui-même mais des scripts qui s’exécutent en réponse aux interactions : ouverture d’un menu, validation d’un formulaire, affichage d’une fenêtre modale de consentement. Chacun de ces scripts, s’il bloque le thread principal trop longtemps, dégrade directement l’INP mesuré, même si le contenu visible à l’écran semblait déjà stable au sens du CLS.
Les scripts les plus souvent responsables
Sur plusieurs audits menés depuis l’annonce du changement de métrique, trois catégories de scripts reviennent systématiquement en tête des causes d’un mauvais INP sur WordPress :
- Les bannières de consentement cookies chargées de façon synchrone, qui exécutent un traitement lourd dès le premier clic de l’utilisateur pour enregistrer son choix
- Les widgets de chat tiers qui initialisent une connexion websocket et un rendu complexe dès l’interaction avec leur bouton flottant
- Les carrousels et menus construits avec des bibliothèques JavaScript généralistes non optimisées, qui recalculent l’intégralité du DOM à chaque interaction plutôt que la seule portion concernée
Le point commun de ces trois cas : le traitement déclenché par l’interaction est disproportionné par rapport à ce que l’utilisateur observe réellement à l’écran. Réduire l’INP consiste souvent à découper ce traitement en tâches plus courtes plutôt qu’à le supprimer entièrement.
Une piste concrète : découper les tâches longues
Sur un gestionnaire d’événement qui exécute plusieurs opérations indépendantes, séparer l’exécution en plusieurs micro-tâches permet de rendre la main au navigateur plus tôt :
button.addEventListener('click', () => {
// Rendu visuel immédiat en priorité
toggleMenuVisibility();
// Traitement secondaire différé après le prochain rendu
requestAnimationFrame(() => {
scheduler.postTask(() => {
trackAnalyticsEvent('menu_open');
preloadSubmenuAssets();
}, { priority: 'background' });
});
});Mesurer l’INP réel, pas seulement en laboratoire
Un outil de laboratoire comme Lighthouse simule des interactions synthétiques et ne reflète pas toujours la charge réelle rencontrée par de vrais visiteurs sur des appareils variés. L’INP fait partie des métriques dites « de terrain », alimentées par le Chrome User Experience Report à partir de données collectées auprès d’utilisateurs réels de Chrome. La Search Console expose ces données dans le rapport Signaux Web essentiels, en distinguant explicitement les URLs classées « Médiocre », « À améliorer » et « Bonnes » sur cette métrique.
Pour un suivi continu sans attendre les mises à jour parfois tardives de la Search Console, la bibliothèque web-vitals officielle permet de faire remonter l’INP mesuré en conditions réelles vers un outil d’analytics propre :
import { onINP } from 'web-vitals';
onINP((metric) => sendToAnalytics(metric));En résumé
Le passage effectif du FID à l’INP en mars 2024 ne change rien à la manière dont Google explore ou classe un site, mais il change ce qui est mesuré et ce qui compte comme un problème de performance. Sur un site WordPress, la priorité se déplace des scripts de chargement initial vers les scripts déclenchés par l’interaction, ce qui demande souvent un audit distinct de celui déjà réalisé pour le LCP ou le CLS.
