Interactions lentes sur WordPress : trouver le JavaScript qui dégrade l’INP

Retrouver une réponse rapide aux clics et aux frappes

Le menu mobile hésite à s’ouvrir, un accordéon reste figé après un clic ou la saisie paraît en retard. La page peut pourtant avoir fini de charger. L’INP, ou délai entre une interaction et le prochain affichage, mesure cette réactivité pour les clics, les pressions tactiles et le clavier au cours d’une visite.

Le repère d’un bon INP est de 200 millisecondes ou moins au 75e percentile des visites, en distinguant mobile et ordinateur. Une mesure locale aide à comprendre un geste lent ; elle ne constitue pas à elle seule le résultat de tous les visiteurs. Une visite sans interaction admissible ne fournit pas la même information qu’un parcours réellement utilisé.

Ce guide cherche à réduire un travail inutile ou excessif sans casser les fonctions de la page. Il propose d’abord un remplacement par un composant natif lorsque le besoin s’y prête, puis une comparaison d’extension. Un retrait de script par page reste une option avancée et facultative, réservée à un fichier dont l’absence d’utilité est confirmée.

Distinguer le premier retour visuel du résultat final

Le navigateur exécute une grande partie de JavaScript sur son fil principal, qui sert aussi à préparer l’affichage et les interactions. Une tâche trop longue peut empêcher un clic d’être traité immédiatement. Ce travail peut venir du composant cliqué, mais aussi d’un autre script occupé au même moment.

L’INP ne mesure pas nécessairement toute la durée d’une recherche ou d’une réponse réseau. Un indicateur peut apparaître rapidement, puis les résultats arriver plus tard. À l’inverse, une petite opération locale peut sembler figée si le navigateur ne peut pas afficher son retour visuel. Il faut mesurer ces phases avant de conclure que le serveur ou le menu est seul responsable.

Ne confondez pas non plus le temps de blocage total d’un test de chargement avec l’INP d’une visite. Un score de laboratoire sans parcours ne dit pas comment répond chaque interaction. Choisissez un geste de lecture reproductible, comme ouvrir un menu ou un détail, et notez ce qui tarde précisément : réaction initiale, animation ou arrivée des données.

Mesurer le même geste dans Chrome

Il vous faut l’URL, un navigateur récent et un parcours défini. Notez la largeur de fenêtre, l’état de connexion, les cookies pertinents et les éventuelles limitations de processeur ou réseau. Une simulation de téléphone ne reproduit pas exactement le matériel réel ; gardez au moins les mêmes réglages pour comparer.

Le résultat attendu est un enregistrement du geste lent avec sa durée et les activités associées. Les rapports peuvent contenir des URL et des données de page : conservez-les dans un espace privé. À la fin, arrêtez l’enregistrement et rétablissez les conditions de navigation modifiées.

1. Ouvrez F12 puis Performance. Rechargez la page et réalisez une première fois le geste choisi, sans formulaire ni paiement réel.
2. Observez la mesure locale d’interaction proposée par le panneau. Lancez ensuite un enregistrement, reproduisez une seule interaction lente, puis arrêtez-le.
3. Sélectionnez l’événement de la piste des interactions. Examinez les délais et la piste Main pour repérer le travail qui occupe le navigateur autour du geste.
4. Répétez avant puis après la fin du chargement. Conservez plusieurs relevés du même parcours au lieu de choisir seulement le meilleur.

Lire l’attente, le traitement et l’affichage

La première phase est le délai avant que le gestionnaire de l’interaction puisse commencer. S’il est long, cherchez la tâche qui occupait déjà le navigateur. Le script du menu peut n’être que la victime d’un autre traitement. Une activité d’analyse, un carrousel ou un composant chargé au démarrage peut participer à cette attente.

La deuxième phase correspond au traitement de l’événement. Un gestionnaire qui trie une grande liste ou reconstruit beaucoup de contenu peut prendre trop de temps. La troisième est l’attente avant le prochain affichage, qui peut inclure du calcul de styles et de mise en page. Réduire seulement le nombre de fichiers ne réduit pas forcément ce travail.

Dans la trace, notez l’URL du script et la fonction associée lorsque l’outil les fournit. Les regroupements Bottom-up ou Call tree aident à identifier les activités coûteuses. Un fichier combiné ou minifié peut masquer son origine : conservez la trace et rapprochez-la des composants installés. Ce relevé sert à choisir une comparaison ciblée, pas à supprimer un fichier parce que son nom apparaît dans le rapport.

Approche 1 : remplacer un simple accordéon par le bloc Détails

Ce parcours convient à un accordéon qui sert uniquement à afficher ou masquer du texte et dont le composant tiers participe à la lenteur. Il demande le droit de modifier la page. Le bloc natif Détails peut remplir ce besoin sans conserver le même composant. Ne l’utilisez pas comme remplacement d’un formulaire, d’un calculateur ou d’une fonction plus complexe.

Travaillez sur une copie et conservez l’ancienne version de la page. Reprenez le contenu complet, les liens et les intitulés utiles. La présentation sera différente ; le résultat à vérifier est un contenu accessible avec une réponse plus rapide au geste, pas une reproduction automatique de tous les effets visuels.

1. Dans Pages, ouvrez Modifier sur la copie. Ajoutez un bloc Détails avec l’outil d’insertion, ou saisissez /details dans un nouveau bloc.
2. Renseignez le résumé visible et placez le contenu correspondant à l’intérieur. Vérifiez les options d’ouverture et, si nécessaire, le nom qui regroupe plusieurs détails en accordéon.
3. Retirez le seul ancien accordéon de cette copie de page, sans supprimer son extension ni les autres contenus. Enregistrez.
4. Contrôlez ouverture, fermeture, liens et usage au clavier, puis mesurez le même geste. Si la fonction ou la présentation ne convient pas, revenez à la version conservée.

Remplacer une intégration secondaire par un lien

Une intégration externe peut ajouter du travail sans être indispensable à la lecture immédiate. Si un aperçu social ou un lecteur secondaire n’est pas utile dans la page elle-même, vous pouvez choisir un lien descriptif vers le contenu. Cette décision change l’expérience : le visiteur quitte la page pour consulter la ressource. Elle ne convient donc pas lorsqu’une lecture intégrée est une fonction attendue.

Le droit d’édition et une version conservée suffisent à cet essai. Sur la copie, vérifiez d’abord l’adresse de destination et le contenu qu’elle ouvre. La diminution du travail doit ensuite être constatée ; retirer le bloc ne garantit pas que son script ne soit plus chargé ailleurs.

1. Dans l’éditeur, ajoutez un paragraphe à l’emplacement de l’intégration secondaire. Écrivez un libellé clair décrivant la ressource.
2. Sélectionnez ce texte, utilisez l’outil de lien ou Ctrl+K, indiquez l’URL vérifiée et appliquez le lien.
3. Retirez le seul bloc d’intégration remplacé et enregistrez sur la copie. Vérifiez destination, compréhension et navigation au clavier.
4. Mesurez de nouveau l’interaction qui était lente. Pour annuler, restaurez la version de page ou le bloc conservé avec ses réglages.

Approche 2 : comparer une extension suspecte sur copie

Ce parcours convient lorsqu’une modification datée ou une trace pointe vers une extension. Il demande une copie fonctionnelle, des droits administrateur et une sauvegarde des fichiers et de la base. Neutralisez ses paiements, courriels et synchronisations sortantes. Le mode de test d’un outil ne remplace pas cette isolation.

Choisissez un seul suspect. Il faut conserver l’interaction que vous mesurez : désactiver le menu qui répond lentement supprime aussi le test. Pour ce cas, comparez plutôt une autre activité concurrente confirmée ou un remplacement fonctionnel préparé. Gardez les dépendances nécessaires et l’état de cache comparable.

1. Ouvrez Extensions, Extensions installées sur la copie. Notez le nom, la version et l’état du composant retenu, ainsi que la mesure initiale.
2. Cliquez sur Désactiver pour ce seul composant. Ne choisissez pas Supprimer. Si une dépendance empêche l’opération, n’élargissez pas arbitrairement la désactivation.
3. Rejouez le geste et vérifiez que sa fonction utile reste disponible. Si elle a disparu, cette comparaison ne démontre pas une accélération de la même action.
4. Réactivez le composant et refaites le relevé. Un défaut qui revient de manière reproductible fournit une piste à l’éditeur ; conservez les traces avant toute décision de production.

Reconnaître les dépendances et le travail de rendu

Un script peut servir à plusieurs fonctions, y compris des composants moins visibles : dialogue, validation de formulaire, navigation mobile ou contenu accessible après connexion. Une bibliothèque partagée peut être appelée par un autre fichier. Son poids ou son nom ne suffit pas à prouver qu’elle est inutile.

Le profilage peut aussi montrer du calcul de styles ou de mise en page plutôt qu’un long gestionnaire JavaScript. Dans ce cas, une page qui contient beaucoup d’éléments ou reconstruit une grande section après chaque geste peut rester lente même avec moins de fichiers. Un bloc replié conserve parfois son contenu dans le document ; le masquer n’équivaut pas à réduire ce travail.

Notez les fonctions réellement utilisées sur la page et dans les états prévus. Si le script est nécessaire, passez à la correction de son comportement avec son éditeur. S’il est confirmé inutile sur cette page seulement, un contrôle de chargement local peut aider. N’utilisez pas cette étape pour retirer globalement jQuery, une validation, un contrôle de sécurité ou un composant de consentement.

Approche 3 : tester Asset CleanUp sur une page précise

Asset CleanUp: Page Speed Booster, de Gabe Livan, peut retirer un fichier JavaScript d’une page où il n’est pas nécessaire. La version Lite gratuite inclut les règles par page et le mode Test. La version vérifiée est 1.4.0.6, compatible déclarée jusqu’à WordPress 7.1.4, avec des minimums annoncés de WordPress 4.7 et PHP 5.6. Ces minimums ne recommandent pas d’utiliser des versions anciennes non maintenues.

Les fonctions Pro, dont des règles plus larges ou l’arrêt complet d’extensions, ne sont pas nécessaires ici. Aucun achat n’est requis pour l’essai décrit. L’outil ne décide pas à votre place si le script sert à une fonction ou à une dépendance.

Ce parcours avancé demande une copie et un administrateur. Avant toute règle, installez Asset CleanUp depuis Extensions, Ajouter, en vérifiant le nom et l’auteur. Dans Asset CleanUp, Settings, ouvrez Test Mode, activez le commutateur puis cliquez sur Save Changes. Conservez l’état initial des réglages.

Le mode Test applique les règles aux sessions connectées autorisées ; les visiteurs ordinaires voient la version non optimisée. Il ne sépare pas les contenus ni la base de données et n’annule aucune règle enregistrée. N’ajoutez pendant cet essai ni combinaison, ni minification, ni report général de JavaScript.

Créer une seule règle de retrait locale

Le fichier retenu doit avoir été rapproché d’une activité coûteuse et confirmé inutile sur cette page. Un script de galerie n’est pas inutile simplement parce que la galerie est plus bas ou masquée au départ. Si vous ne pouvez pas établir ce périmètre, gardez le fichier chargé et transmettez la trace pour analyse.

Le résultat attendu est l’absence du seul fichier choisi dans la version de test, avec l’interaction conservée et une amélioration mesurée. Une règle globale déjà présente ou une exception de chargement peut modifier le résultat. Dans ce cas, examinez les règles existantes sans les supprimer pour forcer votre essai.

1. Dans Pages, repérez la page de copie. Ouvrez son lien Manage CSS & JS proposé par Asset CleanUp, ou son gestionnaire depuis l’édition.
2. Dans la liste CSS & JS Manager, retrouvez le fichier JavaScript par son adresse et son identifiant de chargement. Notez ses règles actuelles.
3. Sélectionnez uniquement Unload on this page. Ne choisissez pas Unload site-wide, une règle de type de contenu ni une expression régulière. Cliquez sur Update pour enregistrer.
4. Dans votre session connectée de test, rechargez la page et vérifiez dans Réseau que le fichier n’est plus demandé. Rejouez ensuite le geste, les fonctions secondaires et les états pertinents.
5. Si une fonction échoue ou si le gain n’est pas établi, décochez cette seule règle et cliquez de nouveau sur Update.

Sortir du mode Test sans appliquer une règle oubliée

Désactiver Test Mode ne supprime pas les règles : cela permet leur application aux visiteurs ordinaires. Avant ce changement, décidez donc si vous conservez le retrait validé ou si vous terminez seulement un diagnostic. Un test externe lancé pendant le mode Test observe généralement la version destinée aux visiteurs et ne confirme pas votre réglage privé.

Pour abandonner l’essai, retirez d’abord la règle locale et enregistrez. Vérifiez le retour du fichier, puis restaurez l’état initial du mode Test. Vous pouvez désactiver l’extension de diagnostic si elle n’avait pas d’autre usage. Ses réglages conservés peuvent revenir lors d’une réactivation ; notez ce qui a été laissé en place.

Pour valider la règle auprès de visiteurs sur la copie, désactivez Test Mode et enregistrez seulement après les contrôles. Actualisez les caches concernés par cette page avec les outils prévus, puis ouvrez une session non connectée. Vérifiez de nouveau fichier, fonctions et délais. Ne supprimez pas manuellement les fichiers de cache générés : des pages peuvent encore les référencer. Le passage en production doit reprendre cette validation et son retour arrière.

Quand le script est nécessaire, corriger son travail

Retirer un fichier nécessaire n’est pas une optimisation utilisable. Si le gestionnaire du clic effectue trop de calculs, l’éditeur doit réduire ou répartir ce travail et permettre un retour visuel rapide. Découper une fonction en plusieurs fonctions ne suffit pas si tout s’exécute toujours dans la même tâche continue.

Le responsable du code peut examiner la taille des données traitées, les mises à jour du document et les calculs de présentation déclenchés. Il peut aussi séparer le travail non urgent en tâches appropriées. Cette adaptation dépend du composant et de ses contraintes ; un fragment JavaScript générique collé dans le pied de page ne réparera pas son gestionnaire.

Reporter tous les scripts au premier clic peut déplacer le problème : ce premier geste déclenche alors leur téléchargement, leur préparation et leur exécution. Les attributs async ou defer ne retirent pas le coût du travail qui s’exécute ensuite. Conservez l’ordre des dépendances et mesurez les interactions de démarrage comme celles plus tardives. Transmettez les traces et l’état exact des réglages à l’éditeur, plutôt que d’accumuler des exclusions non comprises.

Vérifier la fonction, les erreurs et le contexte visiteur

Après chaque changement, mesurez plusieurs fois le même geste et vérifiez qu’il produit toujours le résultat attendu. Contrôlez aussi le clavier, le menu mobile, les contenus ouverts plus tard et les états connecté ou non connecté concernés. Sur une boutique ou un formulaire, utilisez l’environnement et les moyens de test prévus, sans envoi ni paiement réel.

Ouvrez la console du navigateur pour repérer d’éventuelles erreurs nouvelles, puis rapprochez-les du changement. Une page silencieuse n’est pas une preuve complète de fonctionnement ; une seule erreur ne désigne pas toujours l’origine de la lenteur. Reprenez les parcours utiles, pas seulement une capture du premier écran.

Gardez les conditions de processeur, réseau et cache comparables. Une session administrateur ou un téléphone réel peut donner un résultat différent du test sur ordinateur. Si une fonction manque, restaurez le bloc, l’extension ou la règle retirée. La correction retenue doit améliorer la réactivité tout en préservant le besoin du visiteur.

Conserver un diagnostic exploitable et suivre les changements

Gardez l’URL, le geste exact, les conditions de mesure, la trace et le composant impliqué. Notez les réglages et règles locales avec leur raison. Recontrôlez après une mise à jour : un fichier peut changer de nom, acquérir une nouvelle dépendance ou devenir utile à un autre état de la page.

Les données de terrain disponibles dans PageSpeed Insights donnent une tendance pour l’URL ou, à défaut, pour toute l’origine. Elles ne fournissent pas automatiquement le clic responsable et ne reflètent pas immédiatement votre dernière modification. Une absence de données INP ne signifie pas que toutes les interactions sont rapides.

Si le défaut subsiste, transmettez à la personne qui maintient le composant les trois phases observées et les comparaisons déjà faites. Précisez si le problème touche le premier geste, un geste répété ou seulement le mobile. Cette information permet de choisir entre un composant plus simple, un chargement mieux limité et une correction du traitement lui-même.

Rejouer le même clic et observer son premier effet visible

Dans la copie WordPress, un bouton affiche un résultat et déclenche un calcul secondaire. Dans la première variante, tout le travail est exécuté pendant le clic avant la mise à jour de l’écran. Dans la seconde, le traitement nécessaire au premier résultat s’achève plus tôt et le calcul secondaire démarre après ce retour. Dans Chrome, la durée médiane de l’événement de clic passe de 256 à 48 ms et le traitement du clic de 240 à 40 ms. Les deux essais aboutissent au même résultat affiché et au même état de fin du calcul secondaire.

Pour reproduire ce contrôle sur votre copie, choisissez un bouton dont le résultat peut être testé sans effet métier. Notez le texte ou le changement d’état attendu juste après le clic, puis l’état final. Dans Performance, commencez un enregistrement, cliquez une seule fois et arrêtez après le résultat. Dans la piste Interactions, repérez le clic et regardez quelle part du délai vient de l’attente avant le traitement, de l’exécution de ses gestionnaires et de l’affichage qui suit.

Vérifier que le travail déplacé s’achève correctement

Sur le banc, une tâche longue reste présente après le premier retour dans la variante différée. La fin du calcul secondaire apparaît après 371 ms en médiane, contre 241 ms lorsque tout le travail s’exécute pendant le clic. Sur votre composant, vérifiez que la mise à jour annoncée à l’écran correspond à ce qui est réellement disponible à ce moment. Si le résultat dépend du calcul, affichez un état d’attente clair et mettez à jour le résultat après la fin. Conservez les erreurs et la possibilité de revenir à l’état précédent.

Rejouez ensuite une deuxième interaction pertinente peu après la première. Un calcul reporté peut encore gêner le prochain clic s’il monopolise le navigateur à ce moment. Si cela arrive, examinez avec le mainteneur comment raccourcir ou fractionner le travail qui bloque. Sur la copie, restaurez la version précédente si l’ordre des actions ou le résultat de la fonction change. Refaites le parcours complet après le retour.

Comparer la mesure locale et l’expérience des visiteurs

Le banc enregistre la durée de l’événement de clic dans Chrome, le temps de traitement et le retour du résultat à l’écran. Il rejoue trois fois chaque variante et conserve les médianes. Ce relevé décrit une action dans une session de test. Pour suivre l’INP des visiteurs, recherchez les interactions lentes dans les données de terrain disponibles, puis reproduisez les pages et les gestes qui reviennent dans ces observations.

Si votre enregistrement montre un délai avant le début du traitement, examinez le travail déjà en cours à l’arrivée du clic. Si le gestionnaire lui-même occupe l’essentiel du temps, ciblez ce composant avant de retirer un script entier. Si le premier retour est rapide et qu’un résultat réseau tarde, gardez l’indication d’attente et mesurez la requête séparément. Vous pourrez ainsi vérifier si la correction concerne la réactivité, le résultat final ou les deux.