Astro islands: when to hydrate, when to stay static

Astro’s islands architecture lets you ship interactive components inside an otherwise static page. The hard part is discipline: every island costs JavaScript, and most of a marketing site does not need any.

The rule of thumb

Ask one question: does this component change after the page loads in response to user input? If the answer is no — navigation, cards, pricing tables, footers — it stays static. If yes — a mobile menu, a category filter, a carousel — it earns a small script or an island.

Prefer vanilla scripts for trivial interaction

A hamburger toggle is ten lines of vanilla JavaScript in a <script> tag. Reaching for a framework island there triples your payload for nothing. In the Quaeris catalogue, no theme ships a framework runtime at all.

Hydration directives, in order of preference

1. client:visible — the default choice; the island loads when scrolled into view.
2. client:idle — for above-the-fold interaction that can wait a beat.
3. client:load — only when the interaction must be ready immediately.

Measure the result

Run astro build and look at the output. A content page should be HTML and CSS with, at most, a few hundred bytes of inline script. If you see a framework chunk on a page without interaction, an island slipped in that should not be there.