L’INP remplace le FID : ce que ça change pour l’optimisation WordPress

Depuis le 12 mars 2024, c’est officiel : Google a remplacé le First Input Delay (FID) par l’Interaction to Next Paint (INP) dans le trio des Core Web Vitals. Aux côtés du LCP (chargement) et du CLS (stabilité visuelle), c’est donc l’INP qui mesure désormais la réactivité d’une page, avec un impact direct sur le classement dans les résultats de recherche.

Ce changement n’est pas cosmétique. Le FID et l’INP ne mesurent pas la même chose, et un site qui obtenait un excellent score FID peut très bien se retrouver en zone rouge sur l’INP. Pour un site WordPress, chargé en plugins et en scripts tiers par nature, cette bascule change concrètement les priorités d’optimisation. Voici ce qu’il faut comprendre, et surtout ce qu’il faut corriger.

FID contre INP : une différence de nature, pas de degré

Le FID mesurait une seule chose : le délai entre la toute première interaction de l’utilisateur (un clic, un tap) et le moment où le navigateur commence à traiter cet événement. C’était une mesure ponctuelle, prise une seule fois par session, et souvent flatteuse : si le thread principal était libre au moment du premier clic, le score était bon, même si le reste de la navigation était laborieux.

L’INP, lui, observe toutes les interactions de la session — clics, taps, pressions de touches — et retient la plus lente (ou une valeur proche du percentile le plus défavorable sur les pages à nombreuses interactions). Surtout, il ne mesure pas seulement le délai avant traitement, mais le temps total jusqu’au prochain rendu visuel : délai d’entrée, temps de traitement du gestionnaire d’événement, et temps de peinture. C’est une mesure beaucoup plus exigeante et beaucoup plus représentative de l’expérience réelle.

Pourquoi WordPress est particulièrement exposé

Un site WordPress accumule souvent, au fil des plugins installés, des dizaines de scripts qui s’exécutent au chargement et qui attachent des écouteurs d’événements sur des éléments de la page : menu mobile, formulaire de recherche, carrousel, popup, chat, widgets de réseaux sociaux. Chacun de ces scripts, pris isolément, semble anodin. Cumulés, ils saturent le thread principal.

Trois causes reviennent systématiquement dans les audits INP sur WordPress :

• Le JavaScript non découpé : un script de plugin qui exécute une fonction longue de 300 ou 400 ms en une seule fois bloque tout traitement d’interaction pendant ce laps de temps, même si l’utilisateur clique ailleurs sur la page.
• Les gestionnaires d’événements empilés : plusieurs plugins qui écoutent chacun le même événement click ou scroll sur des éléments communs, multipliant le travail à chaque interaction.
• Le rendu coûteux après interaction : un menu qui recalcule toute sa mise en page (reflow) à l’ouverture, plutôt que de basculer une simple classe CSS déjà stylée.

Diagnostiquer l’INP sur un site existant

Le Rapport sur l’expérience utilisateur Chrome (CrUX), visible dans la Search Console sous l’onglet Signaux Web essentiels, donne l’INP réel mesuré auprès des visiteurs. C’est la donnée de terrain (field data) à surveiller en priorité, contrairement à un score en laboratoire qui ne reflète qu’un scénario simulé.

Pour localiser précisément quel script pose problème, les outils de développement Chrome restent la meilleure option : l’onglet Performance permet d’enregistrer une interaction et de repérer les tâches longues (« Long Tasks », supérieures à 50 ms) dans le thread principal. Chrome affiche aussi désormais un encart INP directement dans l’onglet Performance Insights lors de l’enregistrement d’une session.

Sur le terrain, l’ordre d’investigation qui fonctionne bien :

1. Identifier dans Search Console les pages qui cumulent le plus d’interactions ayant un INP dégradé.
2. Reproduire une interaction similaire en local avec l’enregistrement Performance de Chrome.
3. Repérer les tâches longues et remonter au script JavaScript responsable via la pile d’appels affichée.
4. Désactiver le plugin suspect temporairement pour confirmer son implication avant toute décision.

Réduire l’INP sur WordPress : les leviers concrets

Une fois le ou les scripts fautifs identifiés, plusieurs pistes s’offrent au développeur :

• Charger les scripts non critiques avec l’attribut defer plutôt que de manière synchrone, via wp_enqueue_script() avec la stratégie defer disponible depuis WordPress 6.3.
• Découper les fonctions JavaScript longues en tâches plus petites, en rendant la main au navigateur entre chaque étape (par exemple via setTimeout ou, sur les navigateurs compatibles, l’API de planification des tâches).
• Auditer réellement l’utilité de chaque plugin tiers : un carrousel, un popup ou un widget social qui n’apporte qu’un gain marginal ne justifie pas de dégrader la réactivité de toute la page.
• Remplacer les animations JavaScript coûteuses par des transitions CSS, qui ne sollicitent pas le thread principal de la même façon.

wp_enqueue_script(
    'mon-plugin-menu',
    plugin_dir_url( __FILE__ ) . 'menu.js',
    array(),
    '1.2.0',
    array( 'strategy' => 'defer', 'in_footer' => true )
);

Cette syntaxe avec le tableau d’arguments pour wp_enqueue_script(), introduite en 6.3, permet de préciser une stratégie de chargement sans dépendre d’un plugin d’optimisation tiers pour ajouter l’attribut après coup.

Avant de charger un nouveau plugin qui promet d’accélérer le site, vérifiez d’abord s’il ne compte pas lui-même trois ou quatre scripts avec leurs propres écouteurs d’événements. En matière d’INP, additionner des optimisations mal codées aggrave souvent le problème plutôt que de le résoudre.

En résumé

Le passage du FID à l’INP en mars 2024 change la donne parce qu’il expose un défaut que le FID masquait : la réactivité d’un WordPress ne se joue pas seulement au premier clic, mais tout au long de la navigation. Pour un site chargé en plugins, cela signifie auditer sérieusement chaque script tiers, privilégier le chargement différé, et surveiller les tâches longues plutôt que de se fier à un score unique. Un bon LCP ne suffit plus à garantir une bonne expérience : l’INP impose de regarder ce qui se passe après le chargement, pendant que l’utilisateur interagit réellement avec la page.