Depuis mars 2024, l'INP a remplacé le FID comme Core Web Vital de la réactivité — et c'est de loin la métrique la plus dure à passer : 43 % des sites échouent encore au seuil des 200 ms en 2026. Sur PrestaShop, la faute en revient presque toujours au JavaScript des modules tiers, à jQuery chargé en bloc et aux handlers d'événements lourds. Voici comment mesurer, diagnostiquer et corriger l'INP sur une boutique.
Pourquoi l'INP est le CWV le plus difficile à corriger
Le LCP se règle souvent avec une image optimisée, le CLS avec des dimensions sur les médias. L'INP ne se règle pas : il se diagnostique interaction par interaction. Là où le FID ne mesurait que le délai avant que le navigateur commence à traiter la première interaction, l'INP mesure la durée complète de chaque interaction (clic, tap, frappe clavier) de la visite, du geste de l'utilisateur jusqu'au paint suivant. La valeur finale est le 98e percentile : une seule interaction lente, même sur une page par ailleurs parfaite, peut faire échouer la métrique.
La mise à jour Google de mars 2026 a encore durci le jeu : l'INP est devenu un signal de classement à part entière, porté au même poids que le LCP et le CLS, et le seuil de pages « Poor » toléré est passé de 25 % à 15 % de l'ensemble des URL. Les seuils officiels restent inchangés : INP ≤ 200 ms = good, entre 200 et 500 ms = needs improvement, au-delà = poor — mesurés au p75 des visites réelles sur 28 jours. Google indique d'ailleurs qu'un resserrement vers 150 ms est envisagé : visez large dès maintenant.
Les trois phases d'une interaction
Pour corriger un INP, il faut savoir où le temps se perd. Chaque interaction se décompose en trois phases :
- Input delay — le temps d'attente avant que l'event handler ne démarre. La main thread est occupée par une long task (parsing JS, hydration, module tiers). Cause n°1 sur PrestaShop.
- Processing time — la durée d'exécution du handler lui-même. Un clic qui déclenche un calcul synchrone de 200 ms ou l'ouverture d'une quick view qui hydrate toute une logique module.
- Presentation delay — le temps de layout, paint et composite pour afficher le résultat. Un DOM de plus de 3 000 nœuds rend cette phase systématiquement plus chère.
Une long task est un bloc de JavaScript qui dépasse 50 ms. Tant qu'elle s'exécute, le navigateur est sourd : un clic pendant une long task de 300 ms attend 300 ms avant que son handler ne démarre.
Mesurer l'INP sur une boutique PrestaShop
Premier piège : Lighthouse ne mesure pas l'INP. Il donne une approximation via le TBT (Total Blocking Time), mais ne reproduit pas les vraies interactions sur du vrai hardware. Or c'est l'INP field (CrUX), au p75, que Google utilise pour le ranking. Deux niveaux de mesure complémentaires :
Niveau 1 — Données field (la vérité qui compte)
- Google Search Console → Core Web Vitals : l'INP y est disponible depuis le départ de la métrique, avec un décalage de 28 jours.
- PageSpeed Insights / CrUX : le p75 de l'INP par URL, pour prioriser les pages à traiter.
Niveau 2 — RUM avec attribution (le diagnostic)
Le field vous dit quelle page échoue, pas quelle interaction. Instrumentez le site avec la bibliothèque web-vitals et son build d'attribution, qui remonte l'élément cliqué et la phase fautive :
<!-- Module PrestaShop : suivi INP avec attribution -->
<script type="module">
import {onINP} from 'https://unpkg.com/web-vitals@4/dist/web-vitals.attribution.js?module';
onINP(({value, attribution}) => {
if (value > 200) {
window.dataLayer.push({
event: 'inp_slow',
inp_ms: Math.round(value),
element: attribution.eventTarget?.tagName,
id_selector: attribution.eventTarget?.id || attribution.eventTarget?.className,
phase: attribution.eventEntry?.name,
page: location.pathname
});
}
});
</script>
Laissez tourner 7 jours, triez par INP décroissant, et les 3 interactions les plus lentes deviennent votre liste de correction. Corrigez-les et le p75 suit presque toujours.
Les trois causes typiques de l'INP sur PrestaShop
1. Le JavaScript des modules tiers et de jQuery
Une boutique PrestaShop standard charge jQuery (souvent deux versions), jQuery UI, et les scripts des modules : slider, quick view, blog, avis clients, module chat, GTM avec ses tags analytics et remarketing. C'est le premier contributeur d'input delay : le médian du web charge 375 Ko de JS tiers, soit plus du double du JS propriétaire. Chaque tag GTM peut patcher addEventListener et fetch, interposant son code avant le vôtre à chaque interaction.
Correction, par ordre de rentabilité :
- Auditer les tags GTM : une boutique accumule facilement 30 tags dont 20 morts. C'est le quick win n°1, zéro ligne de code module.
- Retarder les tiers non critiques : chat, A/B testing, heatmaps se chargent après la première interaction ou en
requestIdleCallback, jamais au chargement. - Dédoublonner jQuery : deux versions chargées = deux parsings + deux exécutions. N'en gardez qu'une, en version récente.
- Purger les scripts inutilisés des modules : beaucoup de modules ne désactivent jamais leur JS sur les pages où ils ne servent pas.
2. Les event handlers lourds
C'est le cas le plus direct : l'utilisateur clique, et le handler tourne pendant 300-400 ms. Les pires sur PrestaShop :
- La navigation à facettes en AJAX : chaque filtre relance une requête, reconstruit la liste de produits et re-sélectionne les facettes. Le processing time explose sur les gros catalogues.
- La quick view : ouverture de la lightbox qui hydrade slider, sélection de déclinaisons et add-to-cart, tout en une interaction.
- L'add to cart : validation, animation du panier, push dataLayer, parfois re-render de tout le header.
Le réflexe à prendre : un handler ne doit jamais exécuter synchronement plus de 50 ms de travail. Découpez la logique coûteuse et calez-la sur les moments de répit :
// PrestaShop : handler add-to-cart allégé
$(document).on('click', '.ajax_add_to_cart_button', function (e) {
e.preventDefault();
// Feedback immédiat : le paint suit le clic
$(this).addClass('added');
// Traitement coûteux différé, pour ne pas bloquer le paint suivant
requestIdleCallback(() => {
const refreshPanel = () => {
// reload du mini-panier + push dataLayer
};
if ('requestIdleCallback' in window) {
requestIdleCallback(refreshPanel, {timeout: 500});
} else {
setTimeout(refreshPanel, 0);
}
});
});
3. Un DOM trop gros
Au-delà de 3 000 nœuds, chaque layout, style recalculation et paint est plus coûteux : la phase de presentation delay de toutes les interactions ralentit mécaniquement. Les gros contributeurs sur PrestaShop : les menus méga, les listes de produits avec toutes leurs déclinaisons rendues dans le HTML, les modules qui injectent des blocs invisibles.
- Mesurez le DOM avec Lighthouse (audit « Avoid an excessive DOM size »)
- Rendez les déclinaisons en AJAX seulement à l'ouverture de la page produit, pas dans la liste
- Supprimez les conteneurs vides que les modules laissent dans le HTML
Plan d'action priorisé
- Semaine 1 — Mesurer : Search Console + CrUX pour le p75 par page, web-vitals attribution en prod pour les 3 interactions les plus lentes. Sans cette étape, vous corrigerez au hasard.
- Semaine 2 — Nettoyer le JS tiers : audit GTM, suppression des tags morts, retard des widgets chat/A-B, dédoublonnage jQuery. Coût faible, gain sur l'input delay de toutes les pages.
- Semaine 3 — Alléger les handlers : facettes AJAX et quick view prioritairement, feedback immédiat + travail différé via
requestIdleCallback. - Semaine 4 — Réduire le DOM : déclinaisons en AJAX, conteneurs morts, menus méga allégés.
- En continu : watch le p75 CrUX et les rapports d'attribution — le resserrement des seuils (150 ms évoqué) arrive.
Conclusion
L'INP est la métrique la plus honnête des Core Web Vitals : elle ne pardonne rien, pas même une page par ailleurs rapide. Sur PrestaShop, le chantier se concentre presque toujours sur les mêmes leviers — assainir le JavaScript tiers, alléger les handlers du tunnel, réduire le DOM — mais rien ne doit être corrigé avant d'être mesuré. Le build d'attribution de web-vitals et les données CrUX vous donnent les interactions exactes à traiter ; le reste n'est que discipline de priorisation.
Besoin d'un audit INP et Core Web Vitals complet sur votre boutique PrestaShop ? Contactez-moi pour en discuter.
