La plupart des sites WordPress obtiennent de bons résultats au test de chargement, mais échouent ensuite discrètement au test INP, car celui-ci ne mesure pas la vitesse à laquelle votre page s'affiche ; il mesure la vitesse à laquelle votre page réagit lorsqu'un utilisateur clique, appuie ou tape réellement. Il s'agit là d'un problème différent, qui réside presque entièrement dans votre code JavaScript.
Ce guide est une version de diagnostic, et non une énième liste de plugins à installer. Je vais vous montrer en quoi consiste réellement INP, comment identifier précisément l'interaction qui ralentit le site, quelles habitudes d'utilisation de WordPress en sont à l'origine, et quel « régime JavaScript » permet réellement d'améliorer les performances.
Principaux enseignements
- En mars 2024, l'INP a remplacé le « First Input Delay » (FID) parmi les indicateurs Core Web Vitals. Il s'agit désormais de l'indicateur pour lequel la plupart des sites WordPress échouent, car il mesure la réactivité réelle lors des interactions, et non la vitesse de chargement initial.
- Un bon INP est inférieur ou égal à 200 ms ; un INP compris entre 200 et 500 ms nécessite des améliorations ; un INP supérieur à 500 ms est jugé médiocre, selon le 75e centile des visites réelles.
- L'INP se compose de trois éléments : le délai d'entrée, le temps de traitement et le délai de présentation ; en identifiant lequel est le plus lent, vous savez exactement ce qu'il faut corriger.
- Sur WordPress, les principaux responsables sont généralement les éditeurs de pages, les widgets de chat en direct, les balises tierces lourdes et les plugins qui chargent du JavaScript à chaque page.
- La solution, c'est un « régime » JavaScript : retarder et différer l'exécution des scripts, charger les widgets lourds derrière une façade, et désactiver les plugins exécutant du code JavaScript dont vous n'avez pas besoin ; il n'y a pas de plugin miracle.
Pourquoi l'INP est l'indicateur Core Web Vitals que la plupart des sites WordPress ne parviennent pas à respecter
Google a remplacé le « First Input Delay » par Interaction avec le prochain tracé en mars 2024, et c'est précisément ce changement qui explique pourquoi de nombreux sites qui étaient auparavant jugés performants ne le sont plus aujourd'hui. Le FID ne mesurait que le délai avant que le navigateur ne commence à traiter votre toute première interaction ; un site pouvait donc obtenir un bon score tout en restant lent à chaque clic suivant.
L'INP est plus strict, car il prend en compte toutes les interactions sur l'ensemble de la visite et rend compte de celle qui se rapproche le plus de la pire. Un bon score est 200 ms ou moins, un temps compris entre 200 et 500 ms doit être amélioré, et tout temps supérieur à 500 ms est jugé médiocre, selon les mesures effectuées au 75e centile de vos visiteurs réels.
WordPress échoue davantage à cet égard que la plupart des autres plateformes, et ce pour une raison simple : il intègre beaucoup de code JavaScript. Entre un constructeur de pages, quelques plugins qui mettent chacun leurs propres scripts en file d’attente, et deux ou trois balises tierces, le thread principal finit par être saturé, et c’est précisément cette saturation qui ralentit l’interaction. Le fait de dépasser votre Largest Contentful Paint ne dit rien à ce sujet, c’est pourquoi je considère l’INP comme une tâche à part entière dans mon Guide sur les Core Web Vitals.
Ce que l'INP mesure réellement : le délai d'entrée, le traitement et la présentation
Voici la partie que la plupart des guides omettent, et c'est justement celle qui permet de corriger l'INP de manière simple, sans avoir à se livrer à des conjectures. Chaque interaction correspond en réalité à la somme de trois intervalles de temps, et votre valeur de ralentissement se situe presque toujours dans l'un d'entre eux.
Retard d'entrée Il s'agit du temps d'attente avant même que votre code ne commence à s'exécuter, généralement parce que le thread principal est occupé à exécuter autre chose. Délai de traitement Est-ce que vos gestionnaires d'événements remplissent bien leur rôle ?. Retard de présentation le navigateur effectue-t-il le rendu et affiche-t-il le résultat à l'écran ? Identifiez la phase qui prend le plus de temps, et vous saurez si le problème vient d'un excès de code JavaScript en arrière-plan, d'un gestionnaire trop lourd ou d'une mise en page trop volumineuse.
| Les trois volets de l'INP | De quoi s'agit-il ? | Problème courant avec WordPress | La solution |
|---|---|---|---|
| Retard d'entrée | Le temps d'attente avant le lancement de votre gestionnaire, pendant que le thread principal est occupé | Les scripts des plugins, des gestionnaires de balises et des générateurs s'exécutent tous en même temps | Retarder et différer l'exécution du code JS non essentiel afin que le thread soit libre lorsque l'utilisateur effectue une action |
| Délai de traitement | Vos gestionnaires d'événements font leur travail | Un widget lourd ou un gestionnaire qui effectue trop d'opérations lorsqu'on clique dessus | Fractionnez le travail, ou chargez le widget derrière une façade jusqu'à ce qu'il soit nécessaire |
| Retard de présentation | Le navigateur effectue le rendu et l'affichage de l'image suivante | Un DOM surdimensionné provenant d'un générateur de pages comportant des éléments profondément imbriqués | Simplifier la mise en page et réduire le nombre d'éléments dans les modèles complexes |
Comment identifier l'interaction la plus lente à l'aide de données réelles recueillies sur le terrain
On ne peut pas corriger une interaction que l'on n'a pas identifiée ; il faut donc partir des données de terrain, et non d'une hypothèse élaborée en laboratoire. Le Rapport sur l'expérience utilisateur de Chrome contient l'INP enregistré par vos visiteurs réels, et PageSpeed Insights l'affiche en haut de chaque URL que vous testez. C'est sur ce chiffre que Google vous note ; c'est donc par là que je commence toujours.
Le problème, c'est que les données de terrain ne sont disponibles que lorsqu'une page génère suffisamment de trafic ; ainsi, un site récent ou peu fréquenté ne dispose souvent pas encore de rapport INP. Dans ce cas, et pour reproduire un clic particulièrement lent, utilisez le panneau « Performance » de Chrome DevTools avec l'interaction enregistrée ; il décompose une interaction unique en les trois parties mentionnées ci-dessus, ce qui vous permet d'identifier celle qui prend le plus de temps. J'ai abordé en détail cette distinction entre les mesures sur le terrain et en laboratoire dans mon analyse de CrUX Vis par rapport à PageSpeed Insights, car choisir le bon, c'est déjà la moitié du chemin.
Les plugins et widgets WordPress qui nuisent à l'INP
Dans la pratique, on retrouve toujours la même poignée de coupables dans presque tous les audits WordPress. Les constructeurs de pages lourds arrivent en tête, car un outil comme Divi ajoute des scripts volumineux et un code HTML profondément imbriqué qui ralentissent à la fois le traitement et l’affichage. Un widget de chat en direct est souvent le pire élément : à lui seul, un script de chat peut ajouter des centaines de millisecondes de temps de traitement.
Viennent ensuite les éléments plus discrets : les configurations d’outils d’analyse et de gestion des balises qui chargent plusieurs scripts tiers, les plugins de diaporamas et de fenêtres contextuelles, ainsi que l’accumulation générale de plugins qui, chacun, mettent en file d’attente du code JavaScript à l’échelle du site, même sur des pages qui ne l’utilisent jamais. Aucun de ces éléments n’est fatal en soi, mais ensemble, ils accaparent le thread principal, et c’est justement un thread accaparé qui transforme un clic en temps d’attente. Un thème plus léger aide également dans ce domaine, ce qui explique en partie pourquoi je continue à insister là-dessus votre thème nuit-il à votre référencement ?.
Le « régime » JavaScript : corriger l'INP sur WordPress, étape par étape
L'objectif de cette solution est simple : libérer le thread principal afin que, lorsqu'un utilisateur interagit avec le site, le navigateur puisse répondre immédiatement. Pour y parvenir, il faut charger moins de code JavaScript, le charger plus tard, et n'exécuter les éléments les plus gourmands en ressources que lorsqu'ils sont réellement nécessaires.
Correction de l'INP de WordPress, en commençant par ce qui permet d'obtenir les meilleurs résultats
- Vérifiez quels éléments chargent du code JavaScript dans chaque modèle et supprimez les plugins dont vous n'avez pas besoin
- Retarder et reporter l'exécution des scripts non essentiels afin que le thread principal soit libre lors du chargement
- Placez les widgets lourds (chat, vidéo, cartes) derrière une façade qui se charge au clic
- Charger les scripts des plugins uniquement sur les pages qui les utilisent, sous certaines conditions
- Effectuer une nouvelle mesure de l'INP sur le terrain et vérifier si l'interaction la plus défavorable s'est améliorée
Commencez par analyser ce que chaque modèle charge réellement, car la milliseconde la moins coûteuse est celle que vous n'ajoutez jamais à la charge de la page. Désactivez les plugins que vous n'utilisez plus, et pour ceux que vous conservez, vérifiez s'ils mettent des scripts en file d'attente sur chaque page ou uniquement lorsque cela est nécessaire.
Ensuite, retardez et différez les scripts non essentiels. La plupart des plugins de mise en cache, y compris LiteSpeed Cache, disposent d’une option “ retarder le JavaScript ” qui bloque les scripts jusqu’à la première interaction de l’utilisateur, ce qui libère le thread pendant les premiers instants cruciaux. Faites toutefois preuve d’une certaine prudence, car le report d’un script dont dépend votre contenu « au-dessus de la ligne de flottaison » peut entraîner son dysfonctionnement ; veillez donc à effectuer des tests après avoir activé cette option.
Le motif de façade C'est la solution la plus efficace pour la plupart des sites. Au lieu de charger un widget de chat en direct ou de vidéo dès le chargement de la page, vous affichez un faux élément léger : un bouton statique ou une vignette qui ressemble à l'original, et le script lourd ne se charge qu'une fois que l'utilisateur clique dessus. Un widget de chat qui ajoutait 300 ms de temps de traitement à chaque interaction n'affecte plus du tout votre INP jusqu'à ce que quelqu'un ouvre effectivement le chat.
Enfin, chargez les scripts des plugins de manière conditionnelle, afin qu'un script de formulaire de contact ou de diaporama n'apparaisse que sur les pages qui l'utilisent, et non sur l'ensemble du site. Cela demande plus d'efforts que d'appuyer simplement sur un bouton, mais c'est souvent ce qui fait la différence entre un site qui échoue sans cesse et un site qui finit par réussir, car cela s'attaque à la source même de l'accumulation des retards d'entrée.
Comment vérifier que votre INP s'est réellement amélioré
Ne vous fiez pas uniquement aux résultats des tests en laboratoire. Les outils de laboratoire simulent un seul cycle d'exécution, mais l'INP est un indicateur de terrain calculé à partir de vos visiteurs réels ; le chiffre qui compte est donc mis à jour progressivement dans CrUX, au fur et à mesure que de nouvelles données sont collectées. Il faut compter quelques semaines après un changement avant que l'INP de terrain ne le reflète pleinement.
En attendant, vérifiez en laboratoire que l'interaction spécifique que vous avez corrigée est plus rapide : enregistrez-la à nouveau dans le panneau « Performances » et assurez-vous que l'élément que vous avez ciblé (temps de réponse, traitement ou affichage) a bien été optimisé. Lorsque les tests en laboratoire montrent que la correction fonctionne et que les chiffres sur le terrain s'améliorent au fil des semaines suivantes, vous savez que la correction est durable.
Alors, est-ce vraiment si difficile que ça de corriger le problème d'INP sur WordPress ?
Honnêtement, ce problème est plus facile à résoudre qu’on ne le croit, à condition de cesser de le considérer comme un problème de vitesse de chargement. Presque tous les cas d’échec INP que je diagnostique sont dus à du code JavaScript qui n’avait pas besoin d’être exécuté à ce moment-là, et l’utilisation du modèle « façade » associée à une mise en place adéquate du « delay-JS » permet d’éliminer la majeure partie du problème sur la plupart des sites.
Alors, ne vous précipitez pas sur les plugins pour trouver une solution ; identifiez laquelle des trois parties est lente, puis utilisez des opérations de découpage, de mise en attente et de report pour libérer le thread principal. Certes, l’étape de chargement conditionnel demande un réel effort, mais c’est généralement celle qui permet de transformer un “ à améliorer ” tenace en « réussi », et cela vaut la peine de la réaliser correctement.
Vous n'arrivez toujours pas à améliorer votre score à l'INP ?
N'hésitez pas à nous contacter ou m'envoyer un courriel et je t'aiderai à identifier l'interaction qui ralentit le système. N'oublie pas que l'INP est avant tout un problème lié à JavaScript ; la solution est donc presque toujours plus à portée de main qu'il n'y paraît.
Vous souhaitez que nos publications apparaissent plus souvent sur Google ?
En un clic, Google affichera ce site dans votre rubrique « À la une ».
Catégories et balises WordPress : comment choisir, et quel est le rôle de vos pages d'archives dans les résultats de recherche ?
Comment corriger une page alternative à l'aide d'une balise canonique correcte, et quelles URL sont correctes
Duplicata sans URL canonique choisie par l'utilisateur : comment Google sélectionne l'URL canonique, et quand ne pas intervenir
