On est fiers de ce chantier, et on va essayer de raconter précisément pourquoi, plutôt que de se contenter d’annoncer un chiffre. Le client, une boutique en ligne d’accessoires pour cyclistes, affichait un INP moyen de 480 millisecondes sur ses pages produit d’après les données réelles remontées par le Chrome UX Report. Le panier abandonné trop tôt et les retours clients sur la lenteur du site avaient fini par convaincre la direction de budgéter un vrai chantier de performance, plutôt qu’une nouvelle campagne d’acquisition.
Six semaines plus tard, l’INP mesuré en conditions réelles était descendu à 160 millisecondes, stable depuis. Voici ce qui a été fait, dans l’ordre, avec ce qui a marché et ce qui n’a servi à rien.
Le diagnostic initial
La première semaine a été entièrement consacrée à la mesure, sans toucher à une seule ligne de code. L’outil PageSpeed Insights donnait un chiffre global, mais c’est l’onglet Performance de Chrome DevTools, avec des enregistrements sur les interactions réelles (ajout au panier, ouverture du sélecteur de taille, changement de couleur), qui a révélé la source du problème : un plugin de recommandations personnalisées qui recalculait l’intégralité de son algorithme de suggestion à chaque interaction sur la page, même sans rapport avec les recommandations elles-mêmes.
Ce qui n’a servi à rien
Avant de creuser plus loin, l’équipe avait tenté deux pistes classiques qui n’ont quasiment rien changé : passer sur un hébergement plus rapide, et activer un plugin de cache supplémentaire. Ces deux leviers agissent sur le temps de réponse serveur et sur le chargement initial, pas sur l’exécution JavaScript après l’affichage de la page, qui est précisément ce que mesure l’INP. Ce constat, un peu frustrant sur le moment, a évité de perdre encore plus de temps sur cette direction.
La correction principale : isoler le calcul lourd
Le plugin de recommandations exécutait son calcul dans un gestionnaire attaché à l’événement click global du document, ce qui le déclenchait sur n’importe quel clic de la page, y compris ceux qui n’avaient rien à voir avec les recommandations. La correction a consisté à restreindre l’écouteur au conteneur concerné uniquement, puis à repousser le calcul lui-même hors du fil principal via un Worker dédié :
const worker = new Worker('/wp-content/plugins/recos/js/calcul-recos.worker.js');
document.querySelector('.bloc-recommandations')?.addEventListener('click', function (evenement) {
worker.postMessage({ produitId: evenement.target.dataset.produitId });
});
worker.onmessage = function (message) {
afficherRecommandations(message.data);
};
Déplacer le calcul dans un Worker libère le fil principal pendant l’opération, ce qui laisse le navigateur peindre immédiatement la réaction visuelle au clic (l’état actif du bouton, par exemple) pendant que le calcul se poursuit en arrière-plan.
Les corrections secondaires
- Découpage d’une fonction de rendu du panier en plusieurs tâches plus courtes, avec
requestIdleCallbackentre chaque étape. - Suppression d’un script de test A/B tiers qui réévaluait ses règles de ciblage à chaque interaction, remplacé par une évaluation unique au chargement.
- Passage du gestionnaire de sélection de taille d’un ré-rendu complet du composant à une mise à jour ciblée du seul élément modifié.
Suivi dans le temps
| Période | INP (p75, terrain) |
|---|---|
| Avant chantier | 480 ms |
| Fin du chantier | 195 ms |
| Trois mois après | 160 ms |
La baisse continue après la livraison s’explique en partie par l’effet naturel du renouvellement du parc d’appareils des visiteurs, mais surtout par l’absence de régression : aucune nouvelle fonctionnalité ajoutée depuis n’a réintroduit de calcul lourd sur le fil principal, grâce à un budget de performance fixé en interne et vérifié à chaque mise en production.
La leçon qu’on retient de ce chantier : chercher la tâche longue précise vaut mieux que soupçonner tout le site en bloc.
Notre verdict
Ce cas confirme une intuition qu’on avait déjà sans l’avoir vérifiée à cette échelle : l’INP se corrige presque toujours en ciblant un ou deux composants précis, pas en optimisant vaguement « tout le site ». Un audit rigoureux des tâches longues, mesuré sur de vraies interactions, coûte moins cher qu’une succession de tentatives à l’aveugle et donne un résultat qui tient dans la durée.
