Core/Dash Dimensión: Load State (INP)
Segmenta el INP por la fase del ciclo de vida de la página cuando ocurrió la interacción. Identifica si tu problema de capacidad de respuesta es una condición de carrera durante la carga o un problema de JavaScript en tiempo de ejecución.
Dimensión: Load State INP (inpls)
La dimensión Load State (INP) registra el estado de preparación del documento en el momento exacto en que se capturó una interacción del usuario. Cada evento INP en el Chrome User Experience Report lleva una etiqueta de estado de carga: una de loading, dom-interactive, dom-content-loaded o complete. CoreDash expone esa etiqueta como una dimensión filtrable y agrupable para que puedas responder la pregunta que las puntuaciones INP brutas no pueden: ¿en qué momento del ciclo de vida de la página ocurrió la peor interacción?
Esa pregunta es la línea divisoria entre dos correcciones de ingeniería completamente diferentes. Un problema de INP que se agrupa durante loading requiere una estrategia de diferimiento de JavaScript. Un problema de INP que se agrupa durante complete requiere reducir el trabajo de los manejadores de eventos, reducir la sobrecarga del framework o dividir tareas largas en tu código de ejecución. Agrupar por estado de carga te da esa separación sin ninguna instrumentación manual.
En los datos de CoreDash de sitios monitorizados, la distribución de interacciones INP por estado de carga es aproximadamente: loading 15%, dom-interactive 20%, dom-content-loaded 25%, complete 40%. La mayoría de las interacciones ocurren después de que la página esté completamente cargada, pero las peores puntuaciones INP se agrupan abrumadoramente en los estados tempranos.
Captura de pantalla

Por qué el Load State importa para INP
La métrica Interaction to Next Paint mide la latencia completa de una interacción del usuario: el retraso de entrada, el tiempo de procesamiento del manejador de eventos y el retraso de presentación hasta el siguiente frame pintado. De esos tres componentes, el retraso de entrada es el que está más directamente controlado por lo que el navegador está haciendo en el momento en que el usuario hace clic o toca.
Durante la carga temprana de la página, el hilo principal está en máxima contención. El navegador está analizando HTML, ejecutando scripts síncronos, construyendo el CSSOM, ejecutando recursos que bloquean el parser y desencadenando ciclos de renderizado uno tras otro. Cada tarea larga en el hilo principal es una ventana durante la cual una interacción del usuario se pone en cola y espera. Esa espera es el retraso de entrada, y es el factor dominante del INP deficiente durante la carga de página.
Las interacciones que llegan después de que document.readyState alcanza complete enfrentan un hilo principal más tranquilo. El navegador ha terminado de cargar. Si el INP sigue siendo malo en esa etapa, la causa no es la contención de carga. Es el JavaScript que tu página ejecuta en respuesta a las acciones del usuario: manejadores de eventos inflados, ciclos de re-renderizado del framework, layout thrashing provocado por scripts o código de terceros no optimizado ejecutándose síncronamente durante la interacción.
El estado de carga es el filtro más rápido para separar esas dos causas raíz.
Los estados de carga
loading
La página no ha terminado de analizar el documento HTML. El hilo principal está ejecutando scripts síncronos, descargando recursos que bloquean el parser y construyendo el DOM inicial. Este es el entorno más hostil para la interacción del usuario. El retraso de entrada está en su punto más alto porque cualquier tarea larga bloquea directamente al navegador de procesar el clic o toque. Los usuarios que interactúan durante esta ventana son típicamente los visitantes más impacientes o aquellos con conexiones rápidas que alcanzan el contenido visible antes de que la página haya terminado de cargar. Sus puntuaciones INP son las peores que recopilarás. Si una proporción significativa de tus eventos INP deficientes llevan el estado loading, mueve los scripts no críticos a defer o async y elimina los recursos que bloquean el parser por encima del pliegue.
dom-interactive
document.readyState alcanza interactive cuando el HTML está completamente analizado y el DOM está construido, pero los subrecursos como imágenes, hojas de estilos y scripts diferidos aún están cargando. Los scripts diferidos comienzan a ejecutarse en este punto, lo que significa que el hilo principal aún puede estar muy ocupado. La hidratación del framework a menudo comienza aquí. Esta es una ventana peligrosa porque la página parece lista para el usuario pero el hilo principal aún está ocupado. El retraso de entrada permanece elevado. Si el INP deficiente se concentra aquí, la solución es la misma que para loading: reducir el volumen de trabajo síncrono que se ejecuta inmediatamente después de que se completa el análisis del DOM.
dom-content-loaded
El evento DOMContentLoaded se ha disparado. El DOM está completo y los scripts diferidos se han ejecutado. La mayoría de los frameworks JavaScript han completado su pasada inicial de hidratación en este punto. La carga de trabajo del hilo principal disminuye y las interacciones comienzan a obtener respuestas más rápidas. Las puntuaciones INP durante este estado son típicamente mejores que los dos estados anteriores, pero aún elevadas en comparación con complete. Si ves una concentración de interacciones deficientes aquí, revisa qué están haciendo tu framework o scripts de aplicación en los manejadores DOMContentLoaded y si el trabajo de hidratación puede dividirse o ceder el control para permitir el procesamiento de entrada entre tareas.
complete
document.readyState alcanza complete cuando todos los recursos, incluyendo imágenes, fuentes e iframes de terceros, se han cargado. Este es el estado estable en el que la página opera durante el resto de la sesión. Un INP deficiente en este estado es un problema puramente de tiempo de ejecución. La página ha terminado de cargar. Si el hilo principal sigue bloqueando interacciones, la causa está en tu ejecución de JavaScript durante la interacción: manejadores de eventos haciendo demasiado trabajo síncrono, actualizaciones del framework desencadenando recálculos de layout costosos o scripts de terceros ejecutando tareas largas continuamente. La solución no se trata de diferimiento. Se trata de reducir el coste de lo que sucede cuando el usuario realmente hace clic.
Flujo de trabajo de depuración
Paso 1: Filtra por estado de carga en CoreDash. Abre la tabla de desglose de INP y agrupa por Load State. Identifica qué estado tiene la mayor proporción de interacciones deficientes (por encima de 200ms). Esto te dice inmediatamente si estás ante un problema de carga o un problema de tiempo de ejecución.
Paso 2: Cruza con URL y dispositivo. Combina la dimensión Load State con la dimensión URL para encontrar qué páginas específicas generan interacciones deficientes durante los estados de carga tempranos. Los dispositivos móviles se ven desproporcionadamente afectados durante la carga porque las CPUs más lentas alargan cada tarea larga.
Paso 3: Adapta la solución al estado. Para loading y dom-interactive, audita tu estrategia de carga de scripts usando la guía de optimización de INP. Mueve los scripts a defer, elimina los recursos que bloquean el renderizado y usa scheduler.yield() para dividir las tareas largas de inicialización. Para complete, perfila tus manejadores de eventos en Chrome DevTools y reduce el trabajo síncrono que desencadenan por interacción.
Regla práctica de ingeniería
Si más del 30% de tus interacciones INP deficientes están etiquetadas como loading o dom-interactive, tu problema de INP es un problema de carga de página y el diferimiento de JavaScript producirá la mayor mejora. Si más del 60% de las interacciones deficientes están etiquetadas como complete, tu problema de INP es un problema de tiempo de ejecución y necesitas optimizar el coste de los manejadores de eventos, no el orden de carga de scripts. Load State (INP) hace esa determinación en una sola vista de tabla, sin requerir una sesión de laboratorio o instrumentación personalizada.