Hydration and INP: Two Different Problems, One Slow Page
Hydration is the process by which a server-rendered HTML page gets JavaScript attached to it so the page becomes interactive. Until hydration completes, buttons do not fire, forms do not submit, and dynamic UI elements do not respond. It is a startup-phase event that happens once per page load.
INP (Interaction to Next Paint) is a Core Web Vital that measures the latency between any user input — a click, a tap, a key press — and the next visual update the browser paints in response. INP captures responsiveness throughout the entire session, not just at load time. A high INP score means the page feels sluggish every time a shopper interacts, regardless of how fast the page loaded.
The core distinction: hydration is a cause; INP is a measurement. Hydration delay can produce a bad INP score, but a page can pass hydration quickly and still post a poor INP due to heavy event handlers, long tasks on the main thread, or third-party scripts firing during interactions.
How Hydration Works and Where It Slows Things Down
During hydration, the browser downloads, parses, and executes the JavaScript bundle, then reconciles that JS with the existing DOM nodes. On a React or Next.js storefront, this means the entire component tree must be re-rendered in memory and event listeners attached before any interaction registers. On large ecommerce PDPs with carousels, variant selectors, and cart logic, hydration bundles routinely exceed several hundred kilobytes of parsed JavaScript.
The critical window is between First Contentful Paint (FCP) and Time to Interactive (TTI). The page looks ready to the shopper, but taps and clicks either queue silently or produce no response. If a shopper taps Add to Cart during this window, the interaction is dropped or delayed until hydration finishes — a direct conversion risk.
Partial hydration and island architecture (used in frameworks like Astro or Fresh) address this by hydrating only the interactive components rather than the full page. This shrinks the hydration window and reduces the JavaScript that must execute before the first meaningful interaction is available.
How INP Is Measured and What Drives It
INP is defined as the single interaction latency at roughly the 98th percentile across all interactions in a session. Google's threshold for a 'good' INP is under 200 milliseconds; 200–500 ms needs improvement; above 500 ms is poor. INP replaced First Input Delay (FID) as a Core Web Vital in March 2024 because FID only captured the first interaction, while INP reflects the full session.
The main contributors to a high INP are long JavaScript tasks blocking the main thread, synchronous layout and style recalculations triggered by event handlers, and render-blocking third-party scripts such as analytics, chat widgets, and ad trackers. None of these are exclusive to the hydration phase — they occur throughout the page lifecycle.
INP is measured in the field via the Chrome User Experience Report (CrUX) and the web-vitals JavaScript library. Lab tools like Lighthouse and WebPageTest can simulate interactions, but field data from real users across device types and network conditions is the authoritative source for INP diagnosis.
Where Hydration and INP Directly Overlap
The overlap zone is the period immediately after a page becomes visually complete but before hydration finishes. Any interaction a user attempts in this window registers as an INP event with a long input delay, because the main thread is occupied executing the hydration workload. This is why audit tools sometimes surface high INP scores specifically on first interactions for SSR/SSG storefronts.
Streaming SSR and selective hydration (available in React 18 via Suspense boundaries) reduce this overlap by allowing parts of the UI to hydrate and become interactive before the full page finishes. Components above the fold — the Add to Cart button, the image gallery — can hydrate first, cutting the INP exposure window even if the full component tree is still loading.
Point-by-Point Comparison
Scope: Hydration is a one-time event at page load. INP is a continuous measurement across every interaction in a session. Fixing hydration improves the first-interaction experience; fixing INP requires attention to every event handler and rendering path.
Measurement: Hydration has no dedicated Web Vital metric — its impact is inferred from TTI, Total Blocking Time (TBT), and the gap between FCP and first interaction success. INP is a first-class Core Web Vital with explicit good/needs-improvement/poor thresholds and direct influence on Google Search ranking signals.
Root causes: Hydration slowness stems from large JavaScript bundles, synchronous data fetching during mount, and client-side reconciliation cost. Poor INP stems from long tasks on the main thread, inefficient event handlers, excessive DOM size, and unoptimized third-party scripts. The two share the main thread as a constraint, but their causes and fixes differ substantially.
Fix priority: For a storefront that is newly interactive (just launched or recently migrated to a JS framework), hydration is the first bottleneck to address because it blocks all early interactions. For a mature storefront with acceptable TTI, INP diagnosis focuses on interaction-specific profiling using Chrome DevTools' Performance panel and the Event Timing API.
Actionable Steps to Improve Both Metrics Together
Start with field data. Pull CrUX data for INP and cross-reference it with lab-measured TTI and TBT for the same pages. If INP is high specifically on first interactions and TBT is also high, hydration is the likely culprit. If INP is high on repeat interactions (product filter toggles, cart quantity updates), the problem is event handler cost, not hydration.
Reduce hydration cost by code-splitting the JavaScript bundle, deferring non-critical components, and adopting progressive or partial hydration patterns. Reduce INP cost by breaking long tasks into smaller chunks using scheduler.postTask or setTimeout yielding, auditing third-party scripts for main-thread impact, and minimizing synchronous DOM reads inside click handlers.
Validate fixes in the field, not just in Lighthouse. INP field data takes 28 days to update in Google Search Console and CrUX, so run both a lab test and a real-user monitoring (RUM) instrument in parallel to confirm improvements register for actual shoppers before the next reporting cycle.