How isolated, independently hydrated islands drastically cut down client-side JavaScript
The <NuxtIsland> component renders a section of a page on the server as plain HTML and then hydrates it in complete isolation from the rest of the page. Everything outside the island stays static and ships no client-side JavaScript at all, which noticeably improves load times on content-heavy pages.
Table of Contents
- 1. What Are Nuxt Islands and Partial Hydration?
- 2. The
Component in Detail - 3. Practical Example: A Comment Section as an Island
- 4. Server Rendering Without Client Hydration
- 5. Difference from Classic SSR with Full Hydration
- 6. When Do Islands Actually Pay Off?
- 7. Interactivity Inside an Island
- 8. Limitations and Pitfalls of Islands
- 9. Conclusion: Less JavaScript, Targeted Interactivity
- 10. Summary
- 11. FAQ
1. What Are Nuxt Islands and Partial Hydration?
With classic server-side rendering, an entire page is rendered to HTML on the server and then fully re-hydrated in the browser, meaning it gets equipped with the application's complete JavaScript. That happens even when most of the page has no interactivity at all, such as a blog article's body text, a product description, or a static footer. The browser still has to download, parse, and execute the whole bundle just to attach event listeners to elements that never change.
Partial hydration flips this principle around: only the sections that genuinely need interactivity are marked as separate islands, and client-side JavaScript is shipped exclusively for those islands. The rest of the page remains plain, unchanged HTML with no hydration whatsoever. In Nuxt 3 this concept is implemented through the experimental <NuxtIsland> component and through server components using the .island.vue suffix.
2. The Component in Detail
A component becomes an island simply by naming its file with the .island.vue suffix, for example CommentSection.island.vue. Nuxt recognizes this naming convention automatically and renders the component on the server as an isolated HTML fragment that can be fetched through its own internal endpoint. The island ships its own minimal JavaScript for hydration, while the surrounding page stays completely untouched.
Inside an island, ordinary Vue features such as ref, computed, or lifecycle hooks continue to work as expected, with one important caveat: props passed from outside must be serializable, since they are effectively transported through the server response when the island is rendered. Functions or complex class instances therefore do not work as props, whereas plain objects, strings, and numbers pass through without issues.
3. Practical Example: A Comment Section as an Island
A typical article page consists mostly of static text, images, and headings that never change once they've been rendered. The comment section at the bottom of the page, on the other hand, is highly interactive: users type text, click like buttons, and watch new comments arrive live. That combination is a perfect fit for an island, because the expensive hydration work stays confined to the small interactive area.
In the example below, the entire article body renders normally without any hydration, while only the comment section is embedded as a self-contained island. As a result, the page ships zero bytes of client-side JavaScript for the large static portion, while the comment section remains fully functional.