Un filtre tarde à réagir, un menu s’ouvre avec retard ou le texte saisi apparaît après un délai, alors que la page charge rapidement. Examinez la réponse à chaque action et le travail de JavaScript. Dans une application avec des Workers ou des iframes, cela inclut les échanges de messages.
Pourquoi un site rapide peut être lent à répondre aux actions
Après le clic, le navigateur doit gérer l'événement, exécuter JavaScript et afficher le cadre mis à jour. Si le thread principal est occupé, du travail attend son tour. Par conséquent, une bonne vitesse de chargement ne garantit pas une réponse rapide des menus, filtres et formulaires.
Déplacer des calculs vers un Web Worker peut libérer le thread principal, mais ajoute des échanges de données. La fenêtre de la page, les Workers et les iframes échangent des messages via postMessage(). Un message envoyé peut attendre avant d’être traité.
Où se produisent des retards dans la file d'attente des messages
Commencez par trois raisons possibles :
- Le destinataire exécute une longue tâche synchrone. Le nouveau message attend que le thread soit disponible.
- Les messages sont trop nombreux. Même des gestionnaires courts créent une file si le travail arrive plus vite qu’il n’est traité.
- Le volume de données est important. La sérialisation à l’envoi et la désérialisation à la réception prennent du temps sur les threads concernés.
Par exemple, une recherche envoie une requête au Worker après chaque lettre saisie. Si le calcul des résultats précédents continue, les requêtes s’accumulent. L’utilisateur a fini de saisir son mot, mais l’application traite encore l’ancienne saisie. Mesurez la fréquence des messages, le temps de traitement et le volume échangé.
Comment INP mesure la réponse de la page
INP, Interaction to Next Paint, évalue la réactivité aux clics, aux appuis tactiles et aux frappes pendant une visite. Le résultat reflète l’une des interactions les plus lentes, selon les règles d’exclusion des valeurs aberrantes. La latence comprend l’attente avant traitement, l’exécution des gestionnaires et le délai jusqu’à l’affichage de l’image suivante.
Une bonne valeur INP ne dépasse pas 200 ms. La plage au-dessus de 200 à 500 ms nécessite une amélioration, au-dessus de 500 ms est considérée comme faible. Pour évaluer un site, le 75e centile des visites est utilisé séparément sur les appareils mobiles et de bureau.
La file d'attente de messages peut contribuer à cette latence lorsque son traitement occupe le thread principal et interfère avec la saisie ou le rendu. Mais le temps de réponse du Worker ne peut pas être automatiquement considéré comme INP.
Revenons à la recherche : la lettre saisie peut apparaître immédiatement, et les résultats seront mis à jour ultérieurement. Le cadre suivant a déjà été montré, même si le travail utile n'est pas encore terminé. Dans un tel scénario, mesurez séparément la réponse aux entrées et le temps nécessaire pour obtenir les résultats réels. Un indicateur de chargement rapide ne prouve pas que la recherche elle-même est devenue plus rapide.
Vérification INP et analyse JavaScript dans Milten
Vérification INP aide à étudier les retards d’interaction lors d’une exécution de test. Sélectionnez la page avec l'action problématique : menu, catalogue, formulaire ou panier. Dans le rapport, vérifiez quelles interactions ont été complétées et quelles causes de retards ont été trouvées. La conclusion s’applique à cet essai et à ses conditions.
JS Scanner analyse JavaScript lors du chargement d'une seule page dans Chromium, sans clics ni défilement. Il affiche la taille et la charge des scripts, l'exécution du code, les tâches de longue durée, les erreurs et les scripts avec un nom d'hôte différent. Une carte des modules à l'intérieur des bundles est disponible si le site fournit des source maps.
Comparez les rapports pour sélectionner une zone à inspecter. Un fichier lourd dans JS Scanner peut expliquer la charge au démarrage de la page, mais sa présence ne prouve pas encore la raison du clic lent. Le comportement après chargement doit être reproduit séparément. Les deux outils vous aident à affiner votre recherche ; ils ne fournissent pas de trace de chaque message entre toutes les fenêtres et tous les Workers.
Le code qui n'a pas été exécuté lors du chargement peut être nécessaire après un clic ou dans un autre état de la page. Veuillez vérifier ces scripts avant de les supprimer. Un script avec un nom d’hôte différent n’est pas nécessairement superflu : le propre CDN du projet peut faire partie de ce groupe.
Comment trouver la cause d'un mauvais INP
- Enregistrez les étapes de reproduction. Spécifiez l’état de la page, de l’appareil et de l’interface. Par exemple : ouvrez un catalogue, saisissez rapidement une requête, puis sélectionnez un filtre.
- S'il existe un RUM ou un CrUX, utilisez les données de terrain pour sélectionner le problème le plus visible. Les analyses de laboratoire ne remplacent pas les statistiques de visites réelles.
- Exécutez une vérification INP et faites correspondre la couverture du rapport à l'activité problématique. S'il n'a pas été reproduit, examinez-le séparément dans le navigateur.
- Explorez le chargement de JavaScript via JS Scanner. Sélectionnez les fichiers suspects et les tâches longues qui peuvent chevaucher des retards.
- Enregistrez le scénario problématique dans DevTools. Pour un Worker ou une iframe, suivez le message envoyé, le traitement démarré, la réponse et l'actualisation de l'écran. Les ID de requête aideront à distinguer la réponse à l’ancienne entrée de la réponse actuelle.
- Après la réparation, répétez les mêmes étapes avec les mêmes paramètres de périphérique, de processeur et de réseau. Comparez plusieurs analyses, puis vérifiez les données de terrain au fur et à mesure qu'elles s'accumulent.
Que changer pour optimiser l'INP
L’optimisation de l’INP commence par réduire le travail qui retarde l’image suivante. Réduisez le travail des gestionnaires synchrones, découpez les tâches longues et laissez le navigateur afficher un retour visuel avant les calculs facultatifs.
Dans une application avec des Workers, vérifiez si tout le travail envoyé est nécessaire. Pour une recherche, regroupez les mises à jour fréquentes et ignorez les résultats obsolètes. Adaptez le délai de debounce à l’interface : un intervalle trop long ralentit lui-même la recherche.
Réduisez les messages aux informations dont le destinataire a besoin. Au lieu de l'intégralité du répertoire, après chaque changement de filtre, il suffit parfois de transmettre les paramètres de la requête. Pour des données binaires appropriées, considérez objets transférables. Envisagez le transfert de propriété : le tampon transféré devient indisponible pour l'expéditeur.
Testez chaque hypothèse séparément. Si vous avez réduit la taille du message, comparez le temps de transmission et de traitement. Si vous avez déplacé le calcul, vérifiez la réponse de l'interface et le temps d'obtention du résultat. Cela montrera quelle modification a aidé.
Est-il possible de voir automatiquement la surcharge de la file d'attente ?
La proposition WICG vise désormais une extension de l’API Long Animation Frames pour détecter une congestion persistante des files de tâches dans les documents et les Workers. Les mesures par message et les coûts de sérialisation ne font pas partie du périmètre actuel.
La proposition est expérimentale. Ne faites pas dépendre le diagnostic des premiers exemples d’observation de delayed-message. Commencez par un parcours reproductible, INP Scanner, une analyse JavaScript et un enregistrement dans DevTools. Suivez une action lente jusqu’au résultat attendu par l’utilisateur.
