Dimension Core/Dash : Load State (INP)

Dimension : Load State INP (inpls)

La dimension Load State (INP) enregistre l'état de préparation du document (document ready state) au moment exact où une interaction utilisateur a été capturée. Chaque événement INP du Chrome User Experience Report contient un tag d'état de chargement : loading, dom-interactive, dom-content-loaded ou complete. CoreDash affiche ce tag sous forme de dimension filtrable et groupable pour vous permettre de répondre à la question à laquelle les scores INP bruts ne répondent pas : à quel moment du cycle de vie de la page la pire interaction s'est-elle produite ?

Cette question sépare deux types de corrections techniques totalement différents. Un problème d'INP concentré durant la phase loading nécessite une stratégie de report du JavaScript. Un problème d'INP concentré durant la phase complete nécessite de réduire le travail des gestionnaires d'événements, d'alléger la surcharge liée au framework ou de découper les long tasks dans votre code au runtime. Le regroupement par load state fournit cette distinction sans aucune instrumentation manuelle.

Dans les données CoreDash des sites suivis, la répartition des interactions INP par load state est d'environ : 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.

Screenshot

Why Load State Matters for INP

La métrique Interaction to Next Paint mesure la latence totale d'une interaction utilisateur : le délai d'entrée (input delay), le temps d'exécution des gestionnaires d'événements et le délai de présentation (presentation delay) avant l'affichage de la frame suivante. De ces trois composants, le délai d'entrée est le plus directement déterminé par ce que fait le navigateur au moment où l'utilisateur clique ou tape.

Lors du chargement initial de la page, le main thread est soumis à une contention maximale. Le navigateur analyse l'HTML, exécute des scripts synchrones, construit le CSSOM, traite des ressources bloquant le parsing et enchaîne les cycles de rendu. Chaque long task sur le main thread représente une fenêtre durant laquelle une interaction utilisateur est mise en attente. Cette attente correspond à l'input delay. C'est le facteur principal d'un mauvais INP lors du chargement de la page.

Les interactions qui surviennent après que document.readyState a atteint l'état complete rencontrent un main thread plus calme. Le navigateur a fini de charger. Si l'INP reste mauvais à cette étape, la cause n'est pas une contention liée au chargement. Il s'agit du JavaScript exécuté par votre page en réponse aux actions de l'utilisateur : gestionnaires d'événements surchargés, cycles de re-rendu du framework, layout thrashing déclenché par les scripts ou code tiers non optimisé s'exécutant de manière synchrone pendant l'interaction.

Le load state est le filtre le plus rapide pour distinguer ces deux causes profondes.

The Load States

loading

La page n'a pas fini d'analyser le document HTML. Le main thread exécute des scripts synchrones, récupère des ressources bloquant le parsing et construit le DOM initial. C'est l'environnement le plus hostile pour l'interaction utilisateur. Le délai d'entrée y est au plus haut car toute long task empêche directement le navigateur de traiter le clic ou l'appui. Les utilisateurs qui interagissent durant cette fenêtre sont généralement les visiteurs les plus impatients ou ceux disposant d'une connexion rapide qui accèdent au contenu visible avant la fin du chargement. Leurs scores INP sont les pires que vous collecterez. Si une part significative de vos mauvais événements INP est associée à l'état loading, déplacez les scripts non critiques vers defer ou async et éliminez les ressources bloquant le parsing au-dessus de la ligne de flottaison.

dom-interactive

document.readyState atteint l'état interactive lorsque l'HTML est entièrement analysé et le DOM construit, mais que les sous-ressources comme 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 moment, ce qui signifie que le main thread peut encore être fortement sollicité. L'hydratation du framework commence souvent ici. C'est une fenêtre dangereuse car la page semble prête à l'utilisateur alors que le main thread reste occupé. Le délai d'entrée reste élevé. Si le mauvais INP se concentre ici, la solution est la même que pour l'état loading : réduisez le volume de travail synchrone exécuté immédiatement après la fin de l'analyse du DOM.

dom-content-loaded

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

complete

document.readyState atteint l'état 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 de runtime. La page a fini de charger. Si le main thread bloque toujours les interactions, la cause réside dans l'exécution de votre JavaScript lors de 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 coûteux, ou des scripts tiers exécutant des long tasks en continu. La correction ne relève pas du report. Il s'agit de réduire le coût de ce qui se produit lorsque l'utilisateur clique réellement.

Debugging Workflow

Étape 1 : Filtrez par load state dans CoreDash. Ouvrez le tableau de répartition de l'INP et regroupez par Load State. Identifiez l'état qui présente la plus grande proportion d'interactions lentes (au-dessus de 200 ms). Cela vous indique immédiatement s'il s'agit d'un problème de chargement ou d'un problème au runtime.

Étape 2 : Croisez 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 touchés de manière disproportionnée pendant le chargement, car les processeurs plus lents prolongent chaque long task.

Étape 3 : Adaptez la correction à l'état. Pour loading et dom-interactive, auditez votre stratégie de chargement des scripts à l'aide du guide Optimize INP. Déplacez les scripts vers defer, éliminez les ressources render blocking et utilisez scheduler.yield() pour découper les long tasks d'initialisation. Pour complete, profilez vos gestionnaires d'événements dans Chrome DevTools et réduisez le travail synchrone qu'ils déclenchent à chaque interaction.

Engineering Rule of Thumb

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 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 de runtime et vous devez optimiser le coût des gestionnaires d'événements, pas l'ordre de chargement des scripts. Load State (INP) permet de trancher en une seule vue de tableau, sans nécessiter de session en lab data ni d'instrumentation personnalisée.