The browser-side process of attaching JavaScript event handlers to server-rendered HTML — the source of most INP regressions on modern ecommerce stores.
Hydration in plain English
When a server-rendered page arrives in the browser, the HTML is already there and rendered to screen, but it's static — clicks don't work, form inputs don't respond, dynamic state isn't tracked. Hydration is the process of the framework (React, Vue, Svelte) walking the DOM, attaching event listeners, and reconnecting the client-side state model. Until hydration completes, the page is visible but uninteractive.
Hydration sounds invisible but it's the single biggest INP killer on modern stores. A user lands on a server-rendered product page that paints in 0.8 seconds — looks instant. But if hydration takes another 2 seconds (parsing 800KB of JS, rebuilding the React component tree, attaching thousands of listeners), the first click during that window blocks the main thread and feels like the page is broken.
The newer patterns address this. Partial hydration (Astro, Marko) only hydrates interactive components and leaves the rest as static HTML — most product pages are 80% static content that doesn't need JS. Streaming SSR (React 18, Next.js App Router) sends HTML in chunks so hydration can start before the full page arrives. Selective hydration prioritizes the components users actually interact with first.
Diagnostic flow: open Chrome DevTools Performance panel, record a page load, look at the main thread between First Contentful Paint and Time to Interactive. Long yellow bars are JavaScript blocking the thread — that's hydration cost. Tools like Web Vitals extension and Lighthouse will report INP issues that trace back to hydration when the metric exceeds 200ms.
Why hydration matters for ecommerce
For ecommerce, hydration cost is what makes "fast" sites feel slow. Your product page paints in under a second but users can't tap Add to Cart for another 1.5 seconds because hydration is still chewing through React. That feels broken. The fix is architectural: reduce client-side JS, lazy-load non-critical components, use frameworks that hydrate selectively. Every megabyte of JS you ship is hydration cost paid by every visitor. The biggest gains come from auditing what actually needs to be interactive on a product page — usually a tiny minority of the component tree.