How would you implement partial hydration or Islands Architecture in Next.js?

Islands Architecture transforms the traditional monolithic hydration model by treating most of a page as static HTML (the 'sea') with isolated interactive components ('islands') that hydrate independently [citation:5]. In Next.js, this is achievable through a combination of React Server Components for static content, strategic 'use client' boundaries for interactive pieces, dynamic imports to control JavaScript loading, and community libraries that provide granular control over when and how components hydrate [citation:8][citation:9].

Next.js App Router's React Server Components (RSC) provide the natural foundation for Islands Architecture. By default, all components are Server Components that render on the server and send zero JavaScript to the client [citation:2]. Only components explicitly marked with 'use client' become interactive islands that hydrate. This means you can build pages where 90% of the UI is static HTML, and only the truly interactive pieces become client components. The key insight is that Server Components can render Client Components, creating clear boundaries where hydration occurs [citation:9].

For components that are below the fold or non-critical, you can use Next.js dynamic imports with SSR disabled. This ensures the component's JavaScript only loads when needed—for example, when the user scrolls to it or after the page becomes interactive [citation:7][citation:8]. This technique dramatically reduces initial bundle size and improves Time to Interactive (TTI).

For granular control over when islands hydrate, you can use the Intersection Observer API to detect when a component becomes visible and load its JavaScript only at that moment. This is particularly valuable for long pages with interactive elements below the fold [citation:6][citation:8]. The library 'react-hydration-on-demand' implements this pattern, allowing components to hydrate only when they enter the viewport [citation:8].

The community library 'next-lazy-hydrate' provides a clean API for deferring component hydration based on multiple triggers like viewport visibility, hover, or browser idle time [citation:8]. This library builds on concepts from 'react-hydration-on-demand' and integrates seamlessly with Next.js. It allows you to control exactly when each island's JavaScript loads and executes, giving you fine-grained performance optimization [citation:8].

One challenge with Islands Architecture is that islands are isolated—they can't share state through React Context because they're separate component trees [citation:5]. The solution is to use a lightweight store like Nano Stores, which works across framework boundaries and is extremely small (less than 1KB). Islands can import the same store and stay synchronized without needing a shared React context provider [citation:5].

Implementing Islands Architecture in Next.js can dramatically improve core web vitals. Traditional hydration forces the browser to parse and execute JavaScript for the entire page, even for static content [citation:8][citation:9]. With partial hydration, initial JavaScript payloads can be reduced by 50-90%, leading to faster Time to Interactive (TTI) and better First Input Delay (FID) [citation:7][citation:8]. For content-heavy sites like blogs, documentation, or e-commerce product pages, this approach often yields Lighthouse scores above 90 without compromising functionality [citation:5].