L'INP mesure la réactivité d'une page à toutes les interactions, pas seulement au premier clic. Pour identifier le filtre ou le bouton fautif, il faut d'abord des données terrain qui nomment l'élément concerné, puis reproduire l'interaction en labo. Sans cette étape, vous corrigez au hasard. La cible recommandée est de 200 ms ou moins au 75e percentile, segmentée mobile et desktop.
Pourquoi l'INP ne se lit pas comme un temps de chargement
Interaction to Next Paint (INP) est une métrique Core Web Vitals stable qui évalue la réactivité globale d'une page en observant la latence de toutes les interactions qualifiantes pendant la visite. La valeur finale correspond à l'interaction la plus longue observée, avec un traitement des valeurs aberrantes (web.dev, Optimize INP).
Autrement dit, un filtre à facettes lent peut dominer la note même si le reste de la page répond vite. À l'inverse, une page peu interactive peut afficher un bon INP sans que cela prouve une bonne expérience.
Pour une expérience correcte, la cible est de 200 ms ou moins, mesurée au 75e percentile des chargements de page, segmentée entre mobile et desktop (web.dev, Web Vitals). Le seuil de 200 ms s'applique à la page, pas à un composant isolé : c'est une contrainte de lecture importante.
Comment savoir si le problème vient du filtre ou du bouton ?
La réponse se construit en deux temps : données terrain, puis laboratoire. L'ordre compte.
Étape 1 — Lire les données terrain pour nommer l'élément
Un outil de Real User Monitoring (RUM) peut fournir la valeur INP d'une page ainsi que le contexte de l'interaction concernée, selon les capacités de l'outil (web.dev, Optimize INP).
Concrètement, cherchez dans vos rapports terrain :
- la page ou le modèle de page concerné (liste de catégorie, fiche produit, panier) ;
- le sélecteur ou le libellé de l'élément interactif ;
- la répartition mobile / desktop ;
- le percentile, pas seulement la moyenne.
Si votre outil ne descend pas au niveau de l'élément, vous ne pouvez pas trancher entre filtre et bouton. Dans ce cas, la première action n'est pas d'optimiser, mais d'instrumenter.
Étape 2 — Reproduire en laboratoire
Une fois l'élément suspect identifié, reproduisez l'interaction dans un environnement contrôlé. L'objectif n'est pas de retrouver la valeur terrain exacte, mais de comprendre où le temps part : traitement du gestionnaire d'événement, rendu, ou attente réseau.
Testez séparément :
- l'ouverture d'un filtre ;
- la sélection d'une valeur de filtre ;
- l'application du filtre ;
- l'ajout au panier depuis la liste ;
- l'ajout au panier depuis la fiche produit.
Chaque interaction a un coût différent. Les regrouper fausse le diagnostic.
Exemple illustratif : deux boutons, deux causes
Exemple hypothétique, sans lien avec un site réel.
Imaginons une boutique de matériel de randonnée. Sur mobile, l'INP de la page catégorie est de 340 ms au 75e percentile. Le rapport terrain indique que l'interaction la plus lente est un tap sur une case à cocher de filtre « imperméable ».
En labo, on observe que la sélection déclenche un recalcul de toute la liste, y compris des images hors écran. Le bouton « ajouter au panier » de la même page, lui, répond en 90 ms.
Conclusion : le coupable est le filtre, pas le bouton. Corriger le bouton n'aurait rien changé à la note. Ces chiffres sont illustratifs et ne représentent aucune mesure réelle.
Tableau de décision : filtre ou bouton ?
| Indice observé | Hypothèse dominante | Première vérification |
|---|---|---|
| Tap sur case à cocher lent | Filtre | Recalcul de liste au changement |
| Clic « appliquer » lent | Filtre | Requête réseau ou re-rendu global |
| Clic « ajouter au panier » lent | Bouton | Appel panier, mise à jour d'état |
| Lenteur sur toutes les interactions | Cause transverse | Script tiers, tâche longue globale |
| Lenteur mobile uniquement | Ressources ou rendu | Poids visuel, animations |
Ce tableau oriente, il ne prouve pas. La preuve vient de la reproduction en labo.
Pourquoi le mobile domine souvent le diagnostic
La segmentation mobile / desktop est recommandée pour mesurer l'INP (web.dev, Web Vitals). Un filtre qui paraît acceptable sur desktop peut dépasser le seuil sur mobile à cause du rendu, du poids des visuels ou d'animations.
Cela signifie qu'un même modèle de page peut afficher deux réalités selon l'appareil. Ne moyennez pas les deux : traitez-les séparément.
Méthode de vérification réutilisable
- Partez du terrain, jamais du labo seul.
- Isolez une interaction à la fois.
- Notez le type d'événement (clic, tap, clavier).
- Comparez mobile et desktop séparément.
- Vérifiez si la lenteur survient pendant ou après le chargement.
- Ne concluez qu'après reproduction.
Cette séquence évite l'erreur la plus fréquente : optimiser un bouton visible alors que la note est tirée par un filtre.
Ce que les sources ne disent pas
Les documents officiels décrivent la métrique, les seuils et la démarche générale. Ils ne fournissent pas de règle prête à l'emploi pour votre thème, votre CMS ou votre outil de filtrage. Toute recommandation qui prétend le contraire doit être vérifiée sur votre propre instrumentation.
De même, aucun seuil ne garantit un résultat commercial. L'INP décrit la réactivité, pas la conversion.
Questions fréquentes
Faut-il optimiser tous les filtres ou seulement le plus lent ?
Commencez par l'interaction qui pèse le plus sur la valeur INP de la page. Corriger un filtre secondaire avant le principal disperse l'effort. Une fois le premier corrigé, remesurez avant de passer au suivant.
Peut-on se fier uniquement à un test en laboratoire ?
Non. Le laboratoire sert à comprendre une cause déjà identifiée sur le terrain. Sans données réelles, vous risquez d'optimiser une interaction que vos visiteurs n'utilisent presque pas.
Pour aller plus loin
La réactivité n'est qu'un volet de l'expérience. Pour travailler la présentation des produits qui alimentent vos listes, voyez préparer une série de photos produit qui aide à choisir. Et si vos filtres servent à composer des offres groupées, composer un bundle produit clair complète utilement la réflexion.