Dimension Core/Dash : État de chargement (INP)

Dimension : Load State INP (inpls)

La dimension État de chargement (Load State INP) enregistre l'état de préparation du document au moment exact où une interaction utilisateur a été capturée. Chaque événement INP dans le rapport d'expérience utilisateur Chrome (CrUX) comporte une balise d'état de chargement : loading, dom-interactive, dom-content-loaded ou complete. CoreDash expose cette balise en tant que dimension filtrable et regroupable afin que vous puissiez répondre à la question à laquelle les scores INP bruts ne peuvent répondre : à quel moment du cycle de vie de la page la pire interaction s'est-elle produite ?

Cette question constitue la ligne de démarcation entre deux correctifs d'ingénierie totalement différents. Un problème d'INP qui se concentre pendant l'état loading nécessite une stratégie de différé (deferral) du JavaScript. Un problème d'INP qui se concentre pendant l'état complete nécessite de réduire le travail du gestionnaire d'événements, de diminuer la surcharge du framework ou de diviser les tâches longues dans votre code d'exécution (runtime). Le regroupement par état de chargement vous offre cette distinction sans aucune instrumentation manuelle.

Dans les données CoreDash sur l'ensemble des sites surveillés, la répartition des interactions INP par état de chargement est approximativement la suivante : loading 15 %, dom-interactive 20 %, dom-content-loaded 25 %, complete 40 %. La majorité des interactions se produisent après le chargement complet de la page, mais les pires scores INP se concentrent massivement dans les premiers états.

Capture d'écran

Pourquoi l'état de chargement est important pour l'INP

La métrique Interaction to Next Paint mesure la latence totale d'une interaction utilisateur : le délai de saisie (input delay), le temps de traitement du gestionnaire d'événements et le délai de présentation jusqu'à la prochaine frame affichée. De ces trois composants, le délai de saisie est celui qui est le plus directement contrôlé par ce que fait le navigateur au moment où l'utilisateur clique ou tape.

Au début du chargement de la page, le thread principal subit une contention maximale. Le navigateur analyse le HTML, exécute les scripts synchrones, construit le CSSOM, exécute les ressources bloquant l'analyseur (parser-blocking) et déclenche des cycles de rendu en chaîne. Chaque tâche longue sur le thread principal est une fenêtre pendant laquelle une interaction utilisateur est mise en file d'attente et patiente. Cette attente correspond au délai de saisie, et c'est le facteur dominant d'un mauvais INP lors du chargement de la page.

Les interactions qui surviennent après que document.readyState a atteint complete font face à un thread principal plus calme. Le navigateur a terminé le chargement. Si l'INP est toujours mauvais à ce stade, la cause n'est pas une contention liée au chargement. Il s'agit du JavaScript que votre page exécute en réponse aux actions de l'utilisateur : des gestionnaires d'événements surchargés, des cycles de re-rendu du framework, du layout thrashing déclenché par des scripts, ou du code tiers non optimisé s'exécutant de manière synchrone pendant l'interaction.

L'état de chargement (Load State) est le filtre le plus rapide pour séparer ces deux causes profondes.

Les états de chargement (Load States)

loading

La page n'a pas fini d'analyser le document HTML. Le thread principal exécute des scripts synchrones, récupère des ressources bloquant l'analyseur et construit le DOM initial. Il s'agit de l'environnement le plus hostile pour l'interaction utilisateur. Le délai de saisie est à son maximum car toute tâche longue empêche directement le navigateur de traiter le clic ou l'appui. Les utilisateurs qui interagissent pendant cette fenêtre sont généralement les visiteurs les plus impatients ou ceux disposant de connexions rapides qui atteignent le contenu visible avant la fin du chargement de la page. Leurs scores INP sont les pires que vous collecterez. Si une part significative de vos mauvais événements INP porte l'état loading, déplacez les scripts non critiques vers defer ou async et éliminez les ressources bloquant l'analyseur au-dessus de la ligne de flottaison (above the fold).

dom-interactive

document.readyState atteint interactive lorsque le HTML est entièrement analysé et que le DOM est construit, mais que les sous-ressources telles que les images, les feuilles de style et les scripts différés sont encore en cours de chargement. Les scripts différés commencent à s'exécuter à ce stade, ce qui signifie que le thread principal peut encore être fortement sollicité. L'hydratation du framework commence souvent ici. C'est une fenêtre dangereuse car la page semble prête pour l'utilisateur, mais le thread principal est toujours occupé. Le délai de saisie reste élevé. Si le mauvais INP se concentre ici, le correctif est le même que pour loading : réduisez le volume de travail synchrone qui s'exécute immédiatement après la fin de l'analyse du DOM.

dom-content-loaded

L'événement DOMContentLoaded s'est déclenché. Le DOM est complet et les scripts différés ont été exécutés. La plupart des frameworks JavaScript ont terminé leur passe d'hydratation initiale à ce stade. La charge de travail du thread principal diminue, et les interactions commencent à obtenir des réponses plus rapides. Les scores INP pendant cet état sont généralement meilleurs que lors des deux états précédents, mais restent élevés par rapport à complete. Si vous constatez une concentration de mauvaises interactions ici, examinez ce que font votre framework ou les scripts de votre application dans les gestionnaires DOMContentLoaded, et vérifiez si le travail d'hydratation peut être fractionné ou soumis à un yield pour permettre le traitement des entrées entre les tâches.

complete

document.readyState atteint complete lorsque toutes les ressources, y compris les images, les polices et les iframes tierces, sont chargées. C'est l'état stable dans lequel la page fonctionne pour le reste de la session. Un mauvais INP à cet état est un pur problème d'exécution (runtime). Le chargement de la page est terminé. Si le thread principal bloque toujours les interactions, la cause réside dans l'exécution de votre JavaScript pendant l'interaction : des gestionnaires d'événements effectuant trop de travail synchrone, des mises à jour de framework déclenchant des recalculs de mise en page (layout) coûteux, ou des scripts tiers exécutant des tâches longues de manière continue. Le correctif ne concerne pas le différé. Il s'agit de réduire le coût de ce qui se passe lorsque l'utilisateur clique réellement.

Flux de travail de débogage

Étape 1 : Filtrer par état de chargement dans CoreDash. Ouvrez le tableau de répartition de l'INP et regroupez par Load State. Identifiez quel état présente la plus grande proportion de mauvaises interactions (supérieures à 200ms). Cela vous indique immédiatement si vous êtes confronté à un problème de chargement ou à un problème d'exécution (runtime).

Étape 2 : Croiser avec l'URL et l'appareil. Combinez la dimension Load State avec la dimension URL pour trouver quelles pages spécifiques génèrent de mauvaises interactions lors des premiers états de chargement. Les appareils mobiles sont affectés de manière disproportionnée pendant le chargement, car des processeurs plus lents rallongent chaque tâche longue.

Étape 3 : Adapter le correctif à l'état. Pour loading et dom-interactive, auditez votre stratégie de chargement de scripts à l'aide du guide d'optimisation de l'INP. Déplacez les scripts vers defer, éliminez les ressources bloquant le rendu et utilisez scheduler.yield() pour diviser les tâches d'initialisation longues. Pour complete, profilez vos gestionnaires d'événements dans les Chrome DevTools et réduisez le travail synchrone qu'ils déclenchent par interaction.

Règle d'or en ingénierie

Si plus de 30 % de vos mauvaises interactions INP sont étiquetées loading ou dom-interactive, votre problème d'INP est un problème de chargement de page et le report (deferral) du JavaScript produira la plus grande amélioration. Si plus de 60 % des mauvaises interactions sont étiquetées complete, votre problème d'INP est un problème d'exécution (runtime) et vous devez optimiser le coût du gestionnaire d'événements, et non l'ordre de chargement des scripts. L'état de chargement (Load State INP) permet de prendre cette décision dans une seule vue de tableau, sans nécessiter de session en laboratoire ou d'instrumentation personnalisée.