Islands without frameworks: streaming HTML and partial hydration for faster sites

Fast first paint is not enough if users tap a button and nothing happens. Islands without frameworks use partial hydration and streaming HTML to deliver useful markup early while keeping JavaScript attached only to the interactive parts of a page.

For content-heavy sites, this approach can be the difference between a page that merely looks ready and one that is actually responsive. The goal is not to reject frameworks, but to understand the underlying pattern well enough to apply it deliberately, whether you use Astro, React streaming, a lightweight server renderer, or a custom build.

Partial hydration is the practical meaning of islands architecture

Islands architecture starts with a simple observation: most pages are not equally interactive everywhere. An article, mast, footer, product copy, legal text, and sidebar links can often be sent as static HTML. A search box, comments widget, cart preview, dark mode toggle, or filter panel may need JavaScript.

Direct answer: partial hydration means hydrating only the interactive regions of a mostly static page instead of rehydrating the entire interface in the browser. In an islands architecture, static HTML forms the page, and small interactive islands receive JavaScript only when they need it.

Recent explanations often describe islands as static HTML in a sea of JavaScript, but the more operational definition is that islands architecture decouples static HTML delivery from JavaScript execution. The browser can receive meaningful markup without also being forced to download, parse, and execute a full application bundle before the page becomes usable.

web.dev describes partial rehydration as a way to identify mostly static parts of a page and reduce their client-side footprint to nearly zero. The interactive regions still hydrate, but the surrounding content does not need to become a client-side application. That is the core performance idea: every part of the page should justify the JavaScript it asks the user’s device to run.

The browser processes HTML in a streaming fashion.

That framing matters because islands are not only a component organization pattern. They are a delivery strategy. If the server can send HTML quickly and the browser can render it progressively, the client should not have to repeat the whole page construction process just to attach a click handler to a small widget.

What changes compared with full-page hydration

In a traditional server-rendered app with full hydration, the server sends HTML so the user sees content sooner. Then the browser downloads JavaScript and hydrates the page so event handlers and state become active. This can improve First Contentful Paint, but it may still create serious Total Blocking Time and Interaction to Next Paint issues because the page can look loaded before event handlers are attached.

That mismatch is common on modern sites: the content appears, the layout is stable enough to invite a click, but the main thread is busy hydrating a large tree. The user experiences the delay, even if a lab report says the page painted quickly.

Partial hydration changes the default. Instead of assuming the whole page must wake up in the browser, it treats HTML as the durable baseline and JavaScript as an enhancement for selected regions.

• Static content remains server-rendered HTML with little or no client-side JavaScript.
• Interactive widgets are isolated into boundaries that can hydrate independently.
• Hydration can be deferred until visibility, interaction, or idle time.
• The main thread does less work during the critical loading path.

Why streaming HTML and partial hydration work better together

Streaming HTML and islands solve different parts of the same performance problem. Streaming server-side rendering lets the server send HTML in chunks that the browser can progressively render as it is received. Partial hydration limits which parts of that HTML need client-side activation.

web.dev explains that when the server streams HTML, the browser can process it incrementally. Between chunks, the browser can yield to the main thread, which improves responsiveness and can help Interaction to Next Paint. This is different from waiting for one large HTML string to be fully generated and delivered before the browser can begin meaningful work.

That is why streaming SSR and islands are complementary, not competing, ideas. Streaming gets useful HTML to the browser sooner. Islands reduce the client-side work that happens after that HTML arrives.

The loading sequence you are trying to create

1. The server begins sending the document shell and above-the-fold content as soon as it is available.
2. The browser parses and renders streamed HTML progressively instead of waiting for the entire response.
3. Static regions remain static; they do not require a hydration pass.
4. Interactive islands receive only the JavaScript they need.
5. Non-critical islands hydrate later, based on visibility, interaction, or browser idle time.

This sequence preserves the strengths of server rendering without turning every page into a client-side application after first paint. It also maps more closely to how users experience a page: they read, scan, scroll, click, and decide. They do not interact with every widget at once.

Performance claims commonly tied to islands and partial hydration include faster FCP and LCP, along with lower INP. The reasoning is straightforward and supported by the delivery model: shipping less JavaScript and deferring island hydration reduces main-thread work, which can improve interaction latency. The exact outcome still depends on your page, code, hosting, network, and device mix.

Why synchronous rendering becomes a bottleneck

React’s streaming APIs are a useful example of the broader shift. web.dev highlights renderToPipeableStream as a streaming approach that handles backpressure better than renderToString. The lesson is not only about React; it is about avoiding synchronous, all-at-once rendering when the browser can benefit from progressive delivery.

A fully synchronous server render can force the browser to wait for the server to finish the complete HTML response. A fully hydrated client can then force the browser to perform a second large unit of work before the page is reliably interactive. Streaming plus islands breaks both of those units into more useful pieces.

How to build islands without frameworks

You do not need to adopt a full islands framework to use the pattern. Frameworks can make the workflow smoother, but the architectural principle is available to any server-rendered site: output HTML first, isolate interactive widgets, and load only the scripts required for those widgets.

Start with a server-first rendering model. Whether your server is a traditional template engine, a custom Node renderer, a static site generator, or an edge runtime, the page should be meaningful without client-side JavaScript. Then add JavaScript as an enhancement to named regions rather than as a global takeover.

Step 1: Treat HTML as the product, not a loading state

The initial response should contain real content: ings, copy, links, navigation, images with appropriate markup, forms where possible, and structured page sections. Avoid sending an empty root element that depends on JavaScript to create the page. That approach undermines the whole point of islands.

For content-first sites, the zero-JavaScript by default idea remains central. Recent commentary continues to recommend islands for blogs, documentation, marketing pages, and commerce pages that are mostly static with a few interactive pockets. Those site types often have large areas that can remain plain HTML without reducing user value.

Step 2: Mark island boundaries explicitly

An island boundary is a contract: this part of the page may need JavaScript, and the rest of the page should not inherit that cost. In a framework, the boundary might be a component with a directive. Without a framework, it can be a server-rendered HTML block with a small script loader that targets a stable element.

For example, the server can render an accessible search form as HTML and then attach enhanced typea behavior only to that form. If the enhancement fails, the form can still submit. If the user never focuses the search field, the typea code may never need to run.

• Give each island a clear purpose, such as search, comments, filters, media controls, or a theme toggle.
• Keep island scripts scoped so one widget does not require a site-wide application bundle.
• Use progressive enhancement when an HTML fallback is practical.
• Prefer small, independent modules over a shared client runtime that all pages must load.

Step 3: Stream the document before every island is ready

If your server can stream, send the shell and stable content as soon as possible. Do not hold back the whole page because a below-the-fold widget needs data or because a non-critical component has not finished rendering. The browser can parse and paint useful sections while later chunks continue to arrive.

This is where streaming HTML and islands reinforce each other. A static article, product description, or documentation section can appear while an interactive review widget, recommendations block, or comments island is still pending. Users get the content path first, and optional interaction follows.

Step 4: Hydrate islands with small entry points

Each island should have a direct script entry point. That entry point should attach event handlers, initialize state, and request any additional data needed for that island. It should not import the whole site application unless the island truly needs it.

This discipline can feel unfamiliar to teams used to a single front-end bundle. But it makes the cost of interactivity visible. If a dark mode toggle requires a large dependency graph, the problem is no longer hidden inside a general app bundle; it is attached to a specific user-facing feature that can be redesigned or simplified.

Choosing which islands hydrate, and when

The most important implementation decision is not the syntax. It is the hydration policy. Modern island implementations commonly use lazy hydration so islands hydrate only on interaction, on visibility, or when the browser is idle instead of hydrating the entire page at once.

A recent 2026 guide frames the benefit clearly: hydration cost can be cut by isolating widgets. In its example, only a search box, comments widget, or dark mode toggle receives JavaScript, while the article content, er, footer, and sidebar remain zero-JavaScript HTML. That is the decision model to apply before choosing tooling.

Hydrate on interaction

Hydrate on interaction when a widget is not useful until the user engages with it. A typea search, expandable filter group, share menu, or modal trigger may not need to run during initial load. The first pointer, keyboard, or focus event can trigger the import and initialization.

This strategy is attractive because it aligns JavaScript work with intent. The trade-off is that the first interaction may pay the initialization cost. For important controls, keep the baseline interaction functional in HTML or preload a small module if delay would harm the experience.

Hydrate on visibility

Hydrate on visibility when a widget becomes relevant as it enters the viewport. Examples include product carousels lower on the page, embedded maps, comments, related content sliders, or comparison tools. The widget can remain inert until the user scrolls near it.

This approach reduces initial main-thread pressure while still preparing functionality before the user clicks. It works best when the island is not above the fold and does not control primary navigation or purchase actions.

Hydrate on idle

Hydrate on idle when the widget is useful but not urgent. A dark mode toggle, personalization control, or secondary account menu may be initialized after the browser has handled critical rendering and input tasks. The key is to avoid competing with early parsing, painting, and user input.

Idle hydration is not a license to ship unnecessary JavaScript. It simply schedules non-critical work more politely. If an island is rarely used, interaction-based hydration may still be better than idle hydration.

Hydrate immediately only when justified

Some islands should hydrate as soon as possible. A primary checkout control, mission-critical dashboard input, or real-time collaboration widget may need immediate interactivity. Islands architecture is not anti-JavaScript; it is anti-automatic-JavaScript.

The practical question is: what must be interactive before the user can accomplish the page’s primary task? Hydrate that first. Everything else should prove its priority.

Framework islands versus framework-free islands

The islands pattern is widely associated with static-first frameworks such as Astro. Astro’s client:* directives are a practical implementation of selective hydration, letting teams choose when a component becomes interactive. That developer experience is one reason islands became easier to adopt at production scale.

But Astro is not the only ecosystem moving in this direction. Recent sources discuss Astro, Marko, SvelteKit, SolidStart, Next.js, and Fresh as part of the broader move toward streaming SSR and selective hydration. These tools differ in syntax, routing, bundling, data loading, and deployment assumptions, yet they share the same pressure: send less JavaScript and make hydration more selective.

Framework-free islands are useful when a team wants the performance model without adopting a new application platform. They can also fit legacy sites where rewriting the front end would be expensive but isolating high-value widgets is achievable.

When a framework helps

• You need repeatable island boundaries across many pages and teams.
• You want integrated bundling, code splitting, routing, and hydration directives.
• Your components already live in a supported UI library ecosystem.
• You need conventions that reduce one-off loader code and implementation drift.

In these cases, a framework can reduce operational complexity. It can also make partial hydration easier to explain to designers, developers, and marketers because the hydration policy is visible in component usage rather than buried in custom scripts.

When framework-free islands are enough

• The site is mostly static and has only a few interactive widgets.
• The team already has a stable server-rendered stack.
• You want to avoid adding a large client runtime for small enhancements.
• You need incremental adoption rather than a full rebuild.

The risk is that custom implementations can become inconsistent. One developer may hydrate on visibility, another may hydrate on page load, and another may import a shared bundle that quietly grows. If you build islands without a framework, document the rules as carefully as you write the code.

How React Server Components, resumability, and adaptive hydration fit

Selective hydration is increasingly discussed alongside React Server Components and resumability. These ideas are not identical, but they respond to the same performance constraint: client-side JavaScript is expensive, and not every UI element needs the same level of client activation.

React Server Components move more work to the server and reduce the amount of client-side code needed for parts of the tree. Streaming React APIs help deliver HTML progressively. Qwik-style resumability takes another path by aiming to resume server-rendered state with less up-front hydration work. Islands sit on this spectrum as a clear boundary-based model: static regions stay static, interactive regions wake up independently.

A recent academic paper on adaptive hydration in React reinforces the same direction. It describes breaking interfaces into independently rendered and hydrated modules, then deferring hydration based on device capability, network conditions, and component importance. That research framing is notable because it treats hydration as a scheduling and prioritization problem, not merely a rendering step.

The shared principle: hydrate less, later, and more intentionally

Whether the technique is islands, Server Components, resumability, or adaptive hydration, the underlying principle is similar. The page should not force every user device to perform the same hydration work at the same moment. A powerful laptop on a fast network and a low-end phone on a constrained connection should not necessarily receive the same interactivity schedule.

That does not mean every project needs advanced adaptive logic. Many sites can gain clarity by making a simpler decision: the article content is static, the search box hydrates on interaction, the comments hydrate on visibility, and the theme toggle hydrates during idle time. The sophistication should match the product’s complexity.

For product teams, this reframes performance planning. Instead of asking only which framework to use, ask which parts of the interface deserve JavaScript, when they deserve it, and how the server can deliver useful HTML before that JavaScript runs.

Performance benefits to expect, and how to validate them

The strongest case for islands without frameworks is not aesthetic minimalism. It is the ability to reduce main-thread work during the moments that shape perceived speed and responsiveness. Streaming HTML improves early rendering by allowing the browser to parse and render chunks progressively. Partial hydration reduces the amount of JavaScript that competes for execution after paint.

web.dev specifically warns that SSR with full rehydration can improve FCP while still creating serious TBT and INP issues. That is the trap: the page looks ready, but the browser is still busy attaching behavior across a large client tree. Users do not judge readiness by architecture diagrams; they judge it by whether the interface responds.

To validate the approach, measure both rendering and interaction. Do not stop after confirming that HTML arrives earlier. Check whether the main thread remains blocked during hydration, whether important controls respond quickly, and whether non-critical widgets are truly deferred.

Useful signals during implementation

• Look for large JavaScript bundles that load on pages with little interactivity.
• Identify components that hydrate even though they render static text or links.
• Watch for event handlers that attach late to elements users can already see.
• Inspect whether below-the-fold widgets execute during initial load.
• Measure interaction latency after first paint, not only paint timing.

Faster FCP and LCP are possible when the browser receives useful HTML sooner and avoids unnecessary render-blocking work. Lower INP is possible when less JavaScript executes during critical interaction windows. These are reasonable expectations based on the mechanics, but they should be confirmed in your own environment rather than treated as guaranteed outcomes.

Design and marketing teams should also participate in validation. If a carousel, personalization banner, or animation island harms responsiveness, the issue is not only technical. It is a product prioritization decision. Islands make those trade-offs easier to see because each interactive feature carries an explicit loading cost.

Trade-offs and limits of islands without frameworks

Partial hydration is not free of complexity. web.dev warns that partial rehydration can complicate caching and client-side navigation, and implementation details vary across frameworks. Those same issues can appear in framework-free builds, sometimes with fewer guardrails.

The first trade-off is state coordination. If islands are independent, shared state becomes a design decision rather than an automatic property of a single application tree. That can be a benefit, because it prevents accidental coupling. It can also be a burden when multiple widgets need to reflect the same cart, account, or filter state.

The second trade-off is navigation. A traditional multi-page site can keep islands simple because each page load starts fresh. A client-side navigation layer may preserve state and reduce full reloads, but it can also reintroduce the complexity that islands were meant to avoid. Teams should decide whether app-like navigation is truly needed for the user journey.

Caching gets more nuanced

Streaming and islands can change how you think about caching. Static HTML fragments, personalized chunks, and island data may have different lifetimes. A marketing page shell may be cacheable, while a cart preview or account widget may need fresh data. If those concerns are mixed too early, caching becomes harder.

A good rule is to keep static and personalized concerns separated for as long as possible. Stream public content quickly, then hydrate or fetch personalized island data only where needed. This preserves more caching opportunities without pretending every part of the page has the same freshness requirement.

Accessibility still comes first

Because islands often defer JavaScript, the HTML baseline must be usable. Buttons need correct semantics. Forms need labels. Links should work as links. If an island fails to hydrate, the result should be a reduced experience, not a broken one, whenever the feature allows it.

This is especially important for framework-free islands, where the team owns the conventions. Do not rely on JavaScript to create essential accessibility semantics after load if those semantics can be rendered directly in HTML.

Developer experience can drift

Frameworks provide conventions; custom architecture requires discipline. Without shared rules, one island may be tiny and progressive while another imports a broad dependency chain. Over time, the site can return to full-page JavaScript by accident.

Prevent drift with a short engineering standard: what qualifies as an island, which hydration triggers are allowed, how scripts are bundled, how fallbacks work, and how performance is reviewed before release. The standard does not need to be elaborate, but it must be explicit.

A practical decision path for content-first teams

If you are planning a new site or modernizing an existing one, start with the page type. Blogs, documentation, marketing pages, and many commerce pages are strong candidates for islands because they are often content-first with a few interactive pockets. A complex dashboard or real-time editor may still benefit from streaming and selective hydration, but it may require a more application-oriented architecture.

Use the following path to decide how far to go.

1. List the primary user task for the page, such as reading, comparing, searching, buying, or contacting.
2. Mark every region that can complete its role as HTML without client-side JavaScript.
3. Identify the regions that need JavaScript for meaningful interaction.
4. Assign each interactive region a hydration trigger: immediate, interaction, visibility, or idle.
5. Decide whether your current stack can stream HTML, and where streaming would change perceived speed.
6. Review bundle boundaries so each island ships only what it needs.
7. Measure paint and interaction metrics after implementation, especially main-thread blocking and input responsiveness.

This path keeps the conversation grounded. It prevents the team from adopting islands as a trend while still shipping a large global bundle. It also prevents the opposite mistake: removing useful interactivity in the name of performance.

What this looks like on a marketing page

A performance-focused landing page might stream the hero, value proposition, proof points, and primary call to action as HTML. The newsletter form can work as a normal form, with enhancement for inline validation. A testimonial carousel below the fold can hydrate on visibility. A pricing calculator can hydrate on interaction when the user chooses to engage with it.

In that scenario, the page is not static in the simplistic sense. It is strategically interactive. JavaScript supports the moments where it adds value instead of occupying the entire page by default.

What this looks like on a commerce page

A commerce page can render product information, images, specifications, reviews summary, and shipping copy as HTML. The variant selector and add-to-cart control may hydrate immediately if they are central to purchase. Recommendations, reviews expansion, and comparison widgets can hydrate later.

This split respects business goals. It keeps the buying path responsive while avoiding unnecessary work for content the shopper may never reach. It also gives marketers and merchandisers a clearer model for deciding which interactive elements deserve priority.

What this looks like on documentation

Documentation is a natural fit for zero-JavaScript defaults. The article, navigation links, code examples, and ings can be plain HTML. Search, copy-to-clipboard buttons, theme toggles, and interactive demos can be isolated islands.

The result is a docs experience that loads and reads quickly, even before enhancements arrive. Developers get the information first, then convenience features as needed.

Islands without frameworks are not a rejection of modern front-end engineering. They are a reminder that the web platform already gives us a powerful baseline: HTML that streams, renders progressively, and works before a client runtime takes over.

The most useful takeaway is simple: stream what the user can read, hydrate only what the user can use, and schedule the rest with intent. If your site is content-first with selective interaction, partial hydration and streaming HTML can help you build a faster, more resilient experience without waiting for a full framework migration.