Nous utilisons des cookies pour améliorer votre expérience, analyser le trafic du site et personnaliser le contenu. Vous pouvez accepter tous les cookies ou choisir les catégories à autoriser. En savoir plus
Optimisation de l'INP pour les pages de détails de produits (PDP) en 2026 | Ordiko
Guide
Optimisation de l'INP pour les pages de détails de produits (PDP) en 2026
Un guide ciblé pour corriger l'Interaction jusqu'au Prochain Peinture (INP) sur les PDPs de commerce électronique en 2026, couvrant l'échange de variantes, la galerie, l'ajout au panier et les modèles de composants serveur React qui déplacent systématiquement l'INP en dessous de 200ms.
PT1H30M
TL;DR. L'INP sur le PDP est amélioré en expédiant moins de JavaScript et en rendant les interactions optimistes. Utilisez les React Server Components pour les parties statiques. Utilisez useOptimistic pour l'échange de variantes et l'ajout au panier. Utilisez startTransition pour les mises à jour non urgentes. Débounchez la recherche avec AbortController. Élevez les regex et évitez le spread dans les gestionnaires d'événements. Objectif : < 200ms p75, atteignable < 100ms.
Ce que mesure l'INP
L'Interaction to Next Paint (INP) mesure le temps le plus long entre une interaction et le rendu sur une page pendant la visite de l'utilisateur. Une "interaction" est un clic, un tap ou une pression de touche qui déclenche JavaScript.
L'INP est calculé comme le pire cas (excluant les rares valeurs aberrantes), pas la moyenne. Un clic de filtre lent peut ruiner votre score INP même si 99 autres interactions étaient rapides.
Valeur INP
Verdict
≤ 200ms
Bon
200ms – 500ms
Besoin d'amélioration
> 500ms
Mauvais
FAQ
Pourquoi l'INP est-il tellement plus difficile que le LCP ?
Le LCP est principalement un problème de CDN et d'optimisation d'image avec des solutions bien comprises. L'INP est le temps d'exécution JavaScript lors de l'interaction utilisateur ; chaque clic peut avoir un goulot d'étranglement différent. Corriger l'INP nécessite une discipline au niveau des composants sur chaque élément interactif de la page.
Les composants serveur React corrigent-ils automatiquement l'INP ?
En grande partie oui. RSC réduit le bundle JS expédié au navigateur, ce qui réduit le travail sur le fil principal, ce qui améliore l'INP. Mais les parties interactives de la page ont toujours besoin de JS client — RSC à lui seul ne corrigera pas un composant client mal écrit qui crée des regex dans onClick.
Quel est le plus grand tueur d'INP sur les PDPs ?
Le rendu lourd côté client des widgets de recommandation ('Souvent achetés ensemble', 'Vous pourriez aussi aimer') qui expédient 50–200Ko de JS et hydratent agressivement lors de la première interaction. Déplacez-les vers des composants serveur ou chargez-les paresseusement derrière IntersectionObserver.
À quelle vitesse une PDP bien optimisée peut-elle obtenir un INP ?
Un INP p75 dans le monde réel en dessous de 100ms est réalisable. Les PDP Ordiko par défaut à 80–160ms p75 INP sans optimisation manuelle. Les thèmes personnalisés qui suivent les modèles de ce guide peuvent descendre en dessous de 100ms de manière cohérente.
Lectures associées
Étape 1 : Profilage, ne devinez pas
Utilisez l'onglet Performance des Chrome DevTools pour enregistrer une session d'interaction PDP. Recherchez :
Longs travaux (barres jaunes > 50ms) pendant les interactions.
Reflows forcés (barres violettes).
Attribution lourde pour les entrées INP.
Ou utilisez l'API Long Animation Frames (LoAF) dans votre RUM :
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
if (entry.duration > 200) {
console.log('Long frame:', entry);
}
}
});
observer.observe({ type: 'long-animation-frame', buffered: true });
Étape 2 : Différer le JS non critique
Les plus grands gains d'INP sur la plupart des PDP proviennent de la suppression ou du report des scripts que vous n'aviez pas besoin de charger de manière anticipée :
Seuls AddToCartButton et VariantSelector sont des composants client. Tout le reste reste sur le serveur. La taille du bundle diminue de 60 à 80 % par rapport à un PDP entièrement client.
Étape 4 : Échange de variante optimiste
Le flux de clic de variante naïf :
L'utilisateur clique sur une variante.
POST à /api/variant/select avec le nouvel ID de variante.
Le serveur renvoie le prix/SKU/image mis à jour.
Re-rendu avec le nouvel état.
Total : 200–500ms de latence perçue. Score INP : mauvais.
L'INP tombe à < 100ms car les mises à jour d'état optimistes se produisent de manière synchrone et le travail du serveur s'exécute dans une transition.
Étape 5 : Galerie et miniature
La galerie de produits est un tueur d'INP courant si elle charge avidement toutes les images. Modèle :
function handleClick(text) {
if (/[<>]/.test(text)) { ... } // regex créée à chaque clic
setItems(prev => [...prev, ...newItems]); // spread dans l'accumulateur
}
Bon :
const TAG_REGEX = /[<>]/; // élevé à la portée du module
function handleClick(text) {
if (TAG_REGEX.test(text)) { ... }
setItems(prev => prev.concat(newItems));
}
Étape 8 : Chargement paresseux en dessous de la ligne de flottaison
Recommandations, avis, produits connexes : placez-les en dessous de la ligne de flottaison et chargez-les paresseusement avec dynamic + ssr: false pour les widgets purement clients, ou chargez-les sur intersection :
Pour les sections rendues sur le serveur, enveloppez-les dans <Suspense> avec PPR activé afin qu'elles soient diffusées après la coque statique.
Mesurer le succès
Après avoir déployé les corrections, les améliorations de l'INP se montrent dans :
Chrome DevTools sous Performance → Web Vitals overlay (synthétique, immédiat).
Votre propre RUM avec la bibliothèque web-vitals (utilisateur réel, quasi temps réel).
Search Console → Core Web Vitals (utilisateur réel, p75 sur 28 jours, 2–4 semaines de retard).
Un PDP typique qui a commencé à 350ms p75 INP et suit ce guide atteint 80–120ms p75 INP dans les 2 à 4 semaines suivant le déploiement.
Comment Ordiko expédie des PDP avec un INP bon par défaut
Les parties statiques du PDP sont RSC (aucun JS client expédié).
Le sélecteur de variantes utilise useOptimistic + Server Actions.
La galerie utilise startTransition + préchargement d'image au survol.
La recherche est débouncée à 200ms avec AbortController.
Le tiroir du panier rend le dernier compte connu de manière optimiste.
INP p75 par défaut : 80–160ms.
FAQ
Pourquoi l'INP est-il si difficile par rapport à l'LCP ? LCP est principalement un problème de CDN et d'optimisation d'image avec des corrections bien comprises. L'INP est le temps d'exécution JavaScript lors de l'interaction de l'utilisateur ; chaque clic peut avoir un goulot d'étranglement différent. Corriger l'INP nécessite une discipline au niveau des composants pour chaque élément interactif sur la page.
Les React Server Components corrigent-ils automatiquement l'INP ? En grande partie oui. RSC réduit le bundle JS expédié au navigateur, ce qui réduit le travail sur le thread principal, ce qui améliore l'INP. Mais les parties interactives de la page ont toujours besoin de JS client — RSC à lui seul ne corrigera pas un composant client mal écrit qui crée des regex dans onClick.
Quel est le plus grand tueur d'INP sur les PDP ? Le rendu lourd côté client des widgets de recommandation ('Fréquemment achetés ensemble', 'Vous pourriez aussi aimer') qui expédient 50 à 200 Ko de JS et hydratent agressivement lors de la première interaction. Déplacez-les vers des composants serveur ou chargez-les paresseusement derrière IntersectionObserver.
Quelle vitesse un PDP bien optimisé peut-il atteindre sur l'INP ? Un INP p75 dans le monde réel sous 100ms est atteignable. Les PDP Ordiko par défaut à 80–160ms p75 INP sans optimisation manuelle. Les thèmes personnalisés qui suivent les modèles de ce guide peuvent obtenir régulièrement moins de 100ms.