Un menu qui hésite après un clic peut coexister avec un excellent score de chargement. Pour améliorer l’INP, travaillez sur une interaction reproductible, pas sur le seul nombre affiché en haut de PageSpeed Insights.
1. Séparer données réelles et test de laboratoire
Dans PageSpeed Insights, commencez par les données d’utilisateurs réels lorsqu’elles existent. Vérifiez si elles concernent l’URL ou l’origine entière, et le type d’appareil. Le test Lighthouse de chargement n’est pas une mesure complète des interactions vécues pendant une visite.
L’INP prend en compte le délai avant traitement, le travail des gestionnaires d’événements et l’attente du prochain affichage. Une réponse serveur rapide ne garantit donc pas un clic réactif.
Choisissez un parcours : ouvrir le menu, filtrer des produits ou ajouter au panier. Notez navigateur, appareil, état de connexion, consentement et action exacte. En l’absence de données réelles, commencez par ces parcours sans inventer de valeur INP terrain.
2. Attribuer le travail et modifier une seule cause
Ouvrez Performance dans Chrome DevTools, enregistrez puis reproduisez l’action. Sélectionnez l’interaction lente et examinez les tâches du thread principal, les fonctions et les URL de scripts. Un chemin d’extension est une piste ; confirmez en désactivant seulement cette fonction sur une copie de test.
Ce diagnostic de console signale les tâches longues quand l’API est disponible. Il ne mesure pas l’INP et n’attribue pas seul la cause :
if (PerformanceObserver.supportedEntryTypes .includes("longtask")) { new PerformanceObserver(list => { for (const task of list.getEntries()) { console.log(task.startTime, task.duration); } }).observe({ type: "longtask", buffered: true });}Classez les corrections :
- Avant le gestionnaire : retirez les scripts inutiles et chargez les modules secondaires à la demande.
- Dans le gestionnaire : réduisez les calculs et découpez le travail non essentiel.
- Avant l’affichage : limitez les modifications répétées du DOM et les mises en page forcées.
Pour du code que vous maintenez, rendez d’abord visible l’état « traitement en cours », puis cédez la main avant une tâche secondaire. Pour une extension, privilégiez son réglage documenté, sa mise à jour ou son remplacement après test. Une minification ne supprime pas un calcul coûteux.
3. Mesurer le résultat sans casser le site
Rejouez plusieurs fois le même parcours avec les mêmes conditions. Comparez les traces, puis contrôlez menu clavier, recherche, variations produit, consentement et paiement. Conservez une version permettant de revenir en arrière.
Après déploiement, surveillez les données réelles : leur agrégation n’affiche pas instantanément le résultat d’un changement. Une mesure locale favorable reste une hypothèse à confirmer chez vos visiteurs.
Erreurs fréquentes
Retarder tout JavaScript, empiler des extensions d’optimisation ou supprimer une bibliothèque partagée peut améliorer un test tout en cassant le parcours. Le blocage temporaire d’un script dans DevTools n’est pas une correction de production.
FAQ et vérification finale
Un cache de page suffit-il ? Il peut aider le serveur sans réduire le travail du navigateur après un clic.
Une tâche longue prouve-t-elle un mauvais INP ? Non : elle doit être reliée à une interaction et à ses délais.
Validez une amélioration répétable, aucune régression fonctionnelle et un suivi terrain avant de clore le diagnostic.
Sources : web.dev, Chrome DevTools.