Islands, and when not to use one

The island architecture is the reason we build on Astro: the page is HTML, and interactivity is opt-in, component by component. What it does not do is decide for you which components deserve one.

The default is no island

Most of what looks interactive on a well-built site is not. An accordion is a details element. A tab strip can be anchor links. A hover state is CSS. A carousel is, more often than not, a scroll container with snap points.

None of those need a framework, and all of them work before any script has loaded.

Three questions before adding one

Before a component gets a client directive, we ask:

1. Does it need state that survives a scroll or a click somewhere else on the page?
2. Would a reader on a slow connection see something broken before it loads?
3. Is there a CSS or platform feature doing 80 percent of this already?

If the answers are no, no and yes, it is not an island. It is a div with an idea about itself.

Pick the directive on purpose

When a component does earn one, the directive matters more than the framework:

• Use client:visible for anything below the fold. Most things are below the fold.
• Use client:idle for behaviour that should exist soon but not now.
• Use client:load only when the very first interaction would otherwise fail.

The gap between client:load and client:visible on an image-heavy page is usually larger than any optimisation you will make afterwards.

What this buys you

A theme that scores well on a synthetic test is not the point. The point is that the words on the page are readable on a bad train connection in the second the HTML arrives, and everything after that is an improvement rather than a prerequisite.