Core/Dash Dimension: Estado de carga (INP)

Dimensión: Estado de carga INP (inpls)

La dimensión Estado de carga (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: puede ser loading, dom-interactive, dom-content-loaded o complete. CoreDash expone esa etiqueta como una dimensión que se puede filtrar y agrupar para que puedas responder la pregunta que las puntuaciones de INP en bruto no pueden: ¿cuándo, en el ciclo de vida de la página, ocurrió la peor interacción?

Esa pregunta es la línea divisoria entre dos soluciones de ingeniería completamente diferentes. Un problema de INP que se concentra durante el estado loading requiere una estrategia de aplazamiento de JavaScript. Un problema de INP que se concentra durante complete requiere recortar el trabajo del manejador de eventos, reducir la sobrecarga del framework o dividir las tareas largas en el código de ejecución (runtime). Agrupar por estado de carga te ofrece esa división sin necesidad de instrumentación manual.

En los datos de CoreDash de los 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 se ha cargado completamente, pero las peores puntuaciones de INP se concentran abrumadoramente en los estados iniciales.

Captura de pantalla

Por qué el estado de carga es importante para el INP

La métrica Interaction to Next Paint mide la latencia completa de una interacción del usuario: el retraso de la entrada (input delay), el tiempo de procesamiento del manejador de eventos y el retraso de la presentación hasta el siguiente frame renderizado. De esos tres componentes, el retraso de la entrada es el que está controlado más directamente por lo que está haciendo el navegador en el momento en que el usuario hace clic o toca.

Durante el inicio de la carga de la página, el hilo principal se encuentra en su nivel máximo de contención. El navegador está analizando el HTML, ejecutando scripts síncronos, construyendo el CSSOM, ejecutando recursos que bloquean el analizador (parser-blocking) y desencadenando ciclos de renderizado consecutivos. Cada tarea larga en el hilo principal es una ventana durante la cual la interacción de un usuario se pone en cola y espera. Esa espera es el retraso de la entrada (input delay), y es el factor dominante de un INP deficiente durante la carga de la página.

Las interacciones que llegan después de que document.readyState alcanza el estado complete se encuentran con un hilo principal más inactivo. 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 sobrecargados, ciclos de re-renderizado del framework, destrucción del diseño (layout thrashing) desencadenada por scripts o código de terceros sin optimizar ejecutándose sincrónicamente durante la interacción.

El estado de carga es el filtro más rápido para separar esas dos causas principales.

Los estados de carga

loading

La página no ha terminado de analizar el documento HTML. El hilo principal está ejecutando scripts síncronos, obteniendo recursos que bloquean el analizador y construyendo el DOM inicial. Este es el entorno más hostil para la interacción del usuario. El retraso de la entrada está en su punto más alto porque cualquier tarea larga bloquea directamente al navegador de procesar el clic o el toque. Los usuarios que interactúan durante esta ventana suelen ser 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 de INP son las peores que recopilarás. Si una parte significativa de tus eventos INP deficientes tiene el estado loading, mueve los scripts no críticos a defer o async y elimina los recursos que bloquean el analizador en la mitad superior de la página (above the fold).

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 estilo y scripts aplazados (deferred) todavía se están cargando. Los scripts aplazados 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 sigue ocupado. El retraso de la entrada sigue siendo elevado. Si el INP deficiente se concentra aquí, la solución es la misma que para loading: reduce 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 aplazados se han ejecutado. La mayoría de los frameworks de JavaScript han terminado 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 de INP durante este estado son típicamente mejores que los dos estados anteriores, pero aún siguen siendo elevadas en comparación con complete. Si ves una concentración de interacciones deficientes aquí, observa qué están haciendo tus scripts de aplicación o framework en los manejadores DOMContentLoaded y evalúa si el trabajo de hidratación puede dividirse en fragmentos (chunked) o cederse (yielded) para permitir el procesamiento de entradas entre tareas.

complete

document.readyState alcanza complete cuando se han cargado todos los recursos, incluyendo imágenes, fuentes e iframes de terceros. Este es el estado estable en el que opera la página durante el resto de la sesión. Un INP deficiente en este estado es un problema puramente de ejecución (runtime). La página ha terminado de cargar. Si el hilo principal sigue bloqueando interacciones, la causa está en la ejecución de tu JavaScript durante la interacción: manejadores de eventos realizando demasiado trabajo síncrono, actualizaciones del framework provocando recálculos de diseño costosos, o scripts de terceros ejecutando tareas largas de forma continua. La solución no se trata de aplazamiento. 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 Estado de carga. Identifica qué estado tiene el mayor porcentaje de interacciones deficientes (por encima de 200 ms). Esto te indica de inmediato si estás ante un problema de carga o un problema de tiempo de ejecución (runtime).

Paso 2: Haz una referencia cruzada con la URL y el dispositivo. Combina la dimensión Estado de carga con la dimensión URL para encontrar qué páginas específicas generan interacciones deficientes durante los primeros estados de carga. Los dispositivos móviles se ven desproporcionadamente afectados durante la carga porque las CPU más lentas alargan cada tarea larga.

Paso 3: Ajusta la solución al estado. Para loading y dom-interactive, audita tu estrategia de carga de scripts utilizando la guía para optimizar el INP. Mueve los scripts a defer, elimina los recursos que bloquean el renderizado y utiliza scheduler.yield() para dividir las tareas de inicialización largas. Para complete, analiza el rendimiento (profile) de tus manejadores de eventos en Chrome DevTools y reduce el trabajo síncrono que desencadenan por cada interacción.

Regla general 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 la página y el aplazamiento 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 ejecución y necesitas optimizar el coste del manejador de eventos, no el orden de carga de los scripts. La dimensión de Estado de carga (INP) toma esa decisión en una sola vista de tabla, sin necesidad de una sesión de laboratorio ni de instrumentación personalizada.