Retour aux métriquesVoir la version optimisée

INP slow

Filtre catalogue bloqué avant le prochain rendu

Cette page simule volontairement un mauvais handler d’interaction. Le changement de catégorie bloque le main thread avant d’afficher les résultats, donc le navigateur ne peut pas peindre le retour visuel immédiatement.

Guide d’analyse INP

Analyse commerciale

Le filtre utilise les produits déterministes du catalogue. Le ralentissement vient d’un travail synchrone volontairement placé avant la mise à jour visuelle.

Catégorie

Aucun filtre appliqué

    Ce qui est mesuré

    INP (interaction jusqu’au prochain rendu visible) mesure le délai entre une action utilisateur et le moment où le navigateur affiche la réponse visuelle suivante. Ici, le changement de filtre bloque le main thread avant que les résultats puissent être peints.

    À éviter

    Ne pas bloquer le main thread dans un handler d'interaction avant d'afficher un retour visuel. Le navigateur doit pouvoir peindre rapidement que l'action a été prise en compte.

    À vérifier

    INP remplace FID (délai avant le premier traitement d’une interaction). FID ne mesurait que le délai avant le début du handler, alors que INP couvre aussi le traitement et l’attente avant le prochain rendu visible.

    Diagnostiquer et corriger une interaction lente

    Une mauvaise valeur INP ne se corrige pas toujours au même endroit. Le premier réflexe consiste à identifier le travail qui bloque le main thread, puis à choisir la stratégie adaptée.

    Ce qui peut entraîner une valeur INP élevée

    Calcul déclenché par l’interaction

    Un clic ou un changement de filtre lance un calcul, un tri ou une agrégation trop coûteuse sur le main thread.

    Payload trop grosse au mauvais moment

    Une API peut renvoyer trop de données. Le coût réseau est une partie du problème, mais le parsing, la transformation et le rendu côté navigateur peuvent aussi retarder le prochain paint.

    Rendu React trop large

    Une mise à jour d’état peut re-render une grande liste ou des composants coûteux alors que seule une petite partie de l’interface devait changer.

    Travail tiers ou transversal

    Analytics, tag managers, composants design system ou logique globale peuvent occuper le main thread au même moment que l’interaction utilisateur.

    Quand

    Avant de déplacer ou découper un traitement, il faut vérifier si tout ce travail est vraiment nécessaire.

    Exemple

    Exemple : éviter de parcourir tout un catalogue à chaque clic si le serveur peut filtrer les produits, paginer les résultats ou réutiliser un calcul déjà effectué.

    Comment améliorer

    Amélioration typique : meilleur algorithme, moins de données à traiter, pagination, filtrage serveur, pré-calcul ou cache applicatif.