Symptôme : un client remonte un score INP (Interaction to Next Paint) classé « à améliorer » dans le rapport Search Console, sur les pages produit d’une boutique WooCommerce. Le site charge visuellement vite, le LCP est bon, mais dès qu’un visiteur clique sur un bouton « ajouter au panier » ou ouvre un onglet d’information produit, un délai perceptible s’installe avant que l’interface ne réagisse.
Ce cas ne revient pas sur ce qu’est l’INP ni sur son remplacement du FID en mars 2024, déjà largement expliqué ailleurs. L’objectif ici est de dérouler la méthode concrète de diagnostic dans DevTools, jusqu’à identifier précisément la fonction JavaScript responsable, puis de corriger.
Étape 1 : reproduire l’interaction lente sous profilage
Dans Chrome DevTools, l’onglet Performance permet d’enregistrer une trace pendant qu’on reproduit manuellement l’interaction problématique. Après avoir ouvert la page produit en navigation privée (pour éviter les extensions qui polluent la trace), on lance l’enregistrement, on clique sur le bouton « ajouter au panier », puis on arrête l’enregistrement une à deux secondes après.
Étape 2 : lire la piste des interactions
La piste « Interactions » en haut du profil affiche chaque interaction utilisateur détectée, avec sa durée totale décomposée en trois phases : le délai d’entrée (input delay), le temps de traitement (processing time) et le délai de présentation (presentation delay). Sur le cas étudié, le temps de traitement représentait à lui seul 340 des 410 ms totales, ce qui oriente immédiatement vers du JavaScript trop long à s’exécuter plutôt que vers un problème de rendu.
Étape 3 : identifier les tâches longues et leur attribution
En zoomant sur la zone de traitement dans la piste principale, plusieurs blocs rouges apparaissent, chacun représentant une tâche longue (« long task »), c’est-à-dire toute tâche JavaScript qui bloque le fil principal plus de 50 ms. Cliquer sur chaque bloc affiche, dans le panneau inférieur, la pile d’appels complète et le fichier source exact, avec la ligne responsable.
Sur ce cas, l’attribution a révélé que trois extensions ajoutaient chacune un gestionnaire d’événement sur le clic du bouton panier : le plugin de recommandations, un plugin de suivi analytics tiers, et le thème lui-même qui recalculait une jauge de stock à chaque clic, même quand celle-ci n’avait pas changé.
Étape 4 : découper les tâches fautives
Une fois la fonction responsable identifiée dans le code du thème (le recalcul de jauge de stock), la correction a consisté à sortir le calcul non essentiel du chemin critique de l’interaction, via un découpage explicite de la tâche avec setTimeout à délai nul, qui rend la main au navigateur entre deux étapes :
document.querySelector('.ajouter-panier').addEventListener('click', (e) => {
ajouterAuPanier(e);
setTimeout(() => {
recalculerJaugeStock();
envoyerEvenementAnalytics();
}, 0);
});Sur les navigateurs qui supportent l’API plus récente scheduler.yield(), cette dernière offre un découpage plus fin et mieux priorisé que setTimeout, en rendant explicitement la main au navigateur entre deux morceaux de travail sans passer par la file d’attente des macrotâches classiques.
Étape 5 : vérifier le gain
Après correction, une nouvelle trace de profilage a montré un temps de traitement de l’interaction ramené à 78 ms, l’essentiel du travail non critique (analytics, jauge) s’exécutant désormais après le premier rendu visuel de la réaction au clic, invisible pour l’utilisateur.
- Toujours reproduire l’interaction en conditions réalistes, avec un CPU throttlé à 4x ou 6x dans DevTools pour approcher un terminal mobile d’entrée de gamme.
- Ne pas se fier à une seule trace : reproduire l’interaction trois ou quatre fois, les tâches de fond du navigateur pouvant varier d’un essai à l’autre.
- Vérifier systématiquement les extensions tierces avant d’incriminer le thème ou WooCommerce lui-même, une bonne partie des tâches longues venant de scripts de tracking ou de personnalisation ajoutés après coup.
Prévention pour la suite
Pour éviter que le problème ne revienne avec le prochain plugin installé, l’équipe a mis en place une revue systématique du panneau Performance de DevTools avant validation de toute nouvelle extension touchant au parcours d’achat, avec un seuil de refus fixé à 150 ms de temps de traitement sur l’interaction « ajouter au panier ».
