Island
An independently interactive client root embedded in server-rendered or static HTML.
Lesson 06 · Advanced frontend rendering
Islands budget interactivity
Estimated time: about 14 minutes
An islands architecture serves most of a page as inert HTML and hydrates explicit interactive regions independently. Its unit of optimization is the interactive widget, not the route.
Do not collapse the vocabulary
Partial hydration
Only selected subtrees hydrate, instead of replaying one client runtime across the whole document.
Selective hydration
A runtime prioritizes when parts of an already hydratable tree become interactive; it need not mean separate roots.
Move the hydration budget
This content page has navigation, search, a gallery, and reviews. Switch architectures and observe the illustrative startup graph.
184 kB illustrative initial JS
One client root couples unrelated regions: simple navigation waits for the same startup as search and reviews.
Loading and hydration are separate decisions
An island can have HTML now while its code waits. Choose the trigger from interaction urgency and failure cost, not from a generic preference for laziness.
| Trigger | Good fit | Failure mode |
|---|---|---|
| Load immediately | Above-fold control likely to be used at once | Spends bandwidth and CPU even without interaction |
| Browser idle | Likely interaction after initial content settles | Idle time is not guaranteed; control may be tapped first |
| Visible | Below-fold carousel, chart, or editor preview | Late loading can miss a fast scroll or create a dead moment |
| Media/query | Capability or viewport-specific enhancement | Responsive state can change after initialization |
| Interaction | Rare, recoverable, non-critical enhancement | The first action pays network latency unless prefetched |
The boundary creates system costs
Duplicate runtimes
Mixed framework islands can repeat libraries, styles, and scheduling overhead. Count bytes after bundling, not component files.
Shared state
Independent roots do not automatically share context. Prefer URL, server state, DOM events, or a deliberately shared client store.
Accessibility
Core navigation and forms should work before hydration where possible. A dormant island must not masquerade as a ready control.
Consistency
Independent hydration can expose intermediate states. Define ownership for data freshness and cross-island updates.
Island drill
Scenario: A documentation page is almost entirely prose. Search needs immediate keyboard interaction; an expensive playground appears below the fold; navigation uses ordinary links. Where does the client boundary begin?
Choose first. Name the code trigger, no-JS behavior, shared-state channel, and measurement plan.
Retrieval practice
How are islands different from code splitting?
Code splitting changes chunk delivery. Islands also define independent client roots and leave non-interactive page regions outside hydration.
Why is “hydrate on visible” not automatically best?
Visibility can arrive before code, the first action may stall, observers have cost, and the region may be critical despite being below the fold.
How can islands communicate without one page root?
Use durable shared channels such as the URL or server state, explicit DOM events, or a consciously shared client store.
What should you measure?
Initial and interaction-triggered JavaScript, parse/evaluation time, time-to-interactive per island, first-interaction delay, duplicated dependencies, and no-JS behavior.
A senior-shaped interview answer
“I’d use islands when most of the page is content and interactivity is sparse. Each cohesive widget becomes an independent client root; ordinary links and read-only content remain HTML.”
“Hydration timing is a separate choice. Immediate controls load early, below-fold expensive widgets can wait for visibility, and core tasks retain progressive HTML behavior.”
“The tradeoff is coordination: roots need explicit state channels, bundles can duplicate runtimes, and the first interaction can pay lazy-load latency. I’d test those costs on representative devices.”
Primary reading
- Astro: Islands architecture — explicit client islands, hydration directives, and deferred server islands.
- MDN: Intersection Observer — the browser mechanism commonly used for visibility-triggered loading.
Use the client execution field guide to compare islands with hydration and resumability. Ask your teaching agent to partition a real page.
Practice
Short recall now helps decide what returns in your review queue.
Quick recall
Recall: Do not collapse the vocabulary
Say your answer first, then reveal the explanation.
An independently interactive client root embedded in server-rendered or static HTML.
Quick recall
Recall: Move the hydration budget
Say your answer first, then reveal the explanation.
This content page has navigation, search, a gallery, and reviews. Switch architectures and observe the illustrative startup graph.
Quick recall
Recall: Loading and hydration are separate decisions
Say your answer first, then reveal the explanation.
An island can have HTML now while its code waits. Choose the trigger from interaction urgency and failure cost, not from a generic preference for laziness.