Performance
Islands architecture
Also called islands.
Islands architecture is shipping JavaScript only for the parts of a page that need it. The rest stays as static HTML.
How it is measured
Count the kilobytes of JavaScript per page and the number of interactive components. In Astro you can see each island marked with `astro-island` and a client directive like `client:visible` or `client:idle`.
Each island hydrates on its own schedule. Static content costs no script, so Total Blocking Time and INP tend to be lower than on a fully hydrated page.
Worked example
An Astro docs page has a search box, a theme toggle, and 3,000 words of static text. With the whole page as an SPA it ships 280 KB of JS and hydrates in 540 ms. As islands it ships 46 KB. Search hydrates on idle and the theme toggle on visible. Total Blocking Time falls from 520 ms to 90 ms.
The comment widget at the bottom becomes `client:visible` and costs nothing until the reader scrolls there.
How it differs
Islands architecture hydrates parts. Hydration in a classic SSR app covers the whole tree. Partial hydration is the broader idea, and islands is one way to implement it. The two differ in that islands are isolated and do not share a global component tree.
Common errors
Making everything an island and losing the benefit. Using `client:load` on everything. Sharing state across islands the hard way. Forgetting that an island above the fold can still delay INP. Assuming zero JavaScript is always achievable.
In practice
Audit each interactive component and assign the cheapest directive that works. Leave static content static and measure the JS size before and after.