Core/Dash Dimension: Load State (INP)

Dimension: Load State INP (inpls)

The Load State (INP) dimension records the document ready state at the exact moment a user interaction was captured. Every INP event in the Chrome User Experience Report carries a load state tag: one of loading, dom-interactive, dom-content-loaded, or complete. CoreDash surfaces that tag as a filterable, groupable dimension so you can answer the question that raw INP scores cannot: when in the page lifecycle did the worst interaction happen?

That question is the dividing line between two completely different engineering fixes. An INP problem that clusters during loading calls for a JavaScript deferral strategy. An INP problem that clusters during complete calls for trimming event handler work, reducing framework overhead, or breaking up long tasks in your runtime code. Grouping by load state gives you that split without any manual instrumentation.

In CoreDash data across monitored sites, the distribution of INP interactions by load state is roughly: loading 15%, dom-interactive 20%, dom-content-loaded 25%, complete 40%. The majority of interactions happen after the page is fully loaded, but the worst INP scores overwhelmingly cluster in the early states.

Screenshot

Why Load State Matters for INP

The Interaction to Next Paint metric measures the full latency of a user interaction: input delay, event handler processing time, and presentation delay to the next painted frame. Of those three components, input delay is the one most directly controlled by what the browser is doing at the moment the user clicks or taps.

During early page load, the main thread is at maximum contention. The browser is parsing HTML, executing synchronous scripts, building the CSSOM, running parser-blocking resources, and triggering render cycles back to back. Every long task on the main thread is a window during which a user interaction gets queued and waits. That wait is input delay, and it is the dominant driver of poor INP during page load.

Interactions that arrive after document.readyState reaches complete face a quieter main thread. The browser is done loading. If INP is still bad at that stage, the cause is not loading contention. It is the JavaScript your page runs in response to user actions: bloated event handlers, framework re-render cycles, layout thrashing triggered by scripts, or unoptimized third-party code executing synchronously during interaction.

Load state is the single fastest filter for separating those two root causes.

The Load States

loading

The page has not finished parsing the HTML document. The main thread is executing synchronous scripts, fetching parser-blocking resources, and building the initial DOM. This is the most hostile environment for user interaction. Input delay is at its highest because any long task directly blocks the browser from processing the click or tap. Users who interact during this window are typically the most impatient visitors or those on fast connections who reach the visible content before the page has finished loading. Their INP scores are the worst you will collect. If a meaningful share of your poor INP events carries the loading state, move non-critical scripts to defer or async and eliminate parser-blocking resources above the fold.

dom-interactive

document.readyState reaches interactive when the HTML is fully parsed and the DOM is built, but subresources such as images, stylesheets, and deferred scripts are still loading. Deferred scripts begin executing at this point, which means the main thread can still be heavily occupied. Framework hydration often starts here. This is a dangerous window because the page looks ready to the user but the main thread is still busy. Input delay remains elevated. If bad INP concentrates here, the fix is the same as for loading: reduce the volume of synchronous work that runs immediately after DOM parsing completes.

dom-content-loaded

The DOMContentLoaded event has fired. The DOM is complete and deferred scripts have executed. Most JavaScript frameworks have finished their initial hydration pass by this point. The main thread workload drops, and interactions start to get faster responses. INP scores during this state are typically better than the two earlier states, but still elevated compared to complete. If you see a concentration of poor interactions here, look at what your framework or application scripts are doing in DOMContentLoaded handlers and whether hydration work can be chunked or yielded to allow input processing between tasks.

complete

document.readyState reaches complete when all resources including images, fonts, and third-party iframes have loaded. This is the steady state the page operates in for the rest of the session. Poor INP at this state is a pure runtime problem. The page is done loading. If the main thread is still blocking interactions, the cause is in your JavaScript execution during interaction: event handlers doing too much synchronous work, framework updates triggering expensive layout recalculations, or third-party scripts running long tasks continuously. The fix is not about deferral. It is about reducing the cost of what happens when the user actually clicks.

Debugging Workflow

Step 1: Filter by load state in CoreDash. Open the INP breakdown table and group by Load State. Identify which state carries the highest share of poor (above 200ms) interactions. This tells you immediately whether you are looking at a loading problem or a runtime problem.

Step 2: Cross-reference with URL and device. Combine the Load State dimension with the URL dimension to find which specific pages generate poor interactions during early load states. Mobile devices are disproportionately affected during loading because slower CPUs lengthen every long task.

Step 3: Match the fix to the state. For loading and dom-interactive, audit your script loading strategy using the Optimize INP guide. Move scripts to defer, eliminate render-blocking resources, and use scheduler.yield() to break up long initialization tasks. For complete, profile your event handlers in Chrome DevTools and reduce the synchronous work they trigger per interaction.

Engineering Rule of Thumb

If more than 30% of your poor INP interactions are tagged loading or dom-interactive, your INP problem is a page load problem and JavaScript deferral will produce the largest improvement. If more than 60% of poor interactions are tagged complete, your INP problem is a runtime problem and you need to optimize event handler cost, not script loading order. Load State (INP) makes that call in one table view, without requiring a lab session or custom instrumentation.