islands

Most of a web page does not need to think. A heading, a paragraph, a photo, a footer with your phone number in it, none of that responds to a click or updates itself. It just needs to appear, fast, and stay put. A small part of the page is different. A booking calendar has to react when you tap a date. A search box has to filter results as you type. Those pieces need real, running code in the visitor’s browser.

An island is that small piece, built and shipped on its own, sitting inside a page that is otherwise plain HTML. The name describes the shape of it: still water everywhere, one patch of activity in the middle. The rest of the page never pays for code it does not use.

This is the opposite of how most page builders and site-building platforms work. They ship one large bundle of JavaScript for the whole page, whether that page needs it or not, because the tool cannot tell in advance which parts will be interactive. An Astro site built with islands can tell, because I tell it, one component at a time.

Why it matters to you

Every byte of JavaScript a visitor’s phone has to download and run before your page feels responsive costs you something: a slower page, a worse PageSpeed score, and a real chance that a visitor on a weak connection gives up before the page finishes loading. Islands mean your homepage, your about page and your service pages carry almost none of that weight, because they have nothing to interact with. The cost only shows up on the one page that has a booking form or a live map, and only for the part of that page doing the work.

It also means a bug in one interactive widget cannot take down a page that has nothing to do with it. The pieces are separate on purpose.

How I set it up

I build the site as plain pages first, in Astro and Markdown, and only reach for an island when a piece of the page genuinely needs to run code after it loads: a form with live validation, a filterable list, a widget from a booking or payment provider. Each one is written as its own small component and loaded only on the pages that use it, not bundled into every page by default.

I also choose, per island, how eagerly it loads. Some load the moment the page appears. Others wait until a visitor scrolls near them, or until the browser is idle. A booking widget below the fold does not need to compete with the page’s first paint for the visitor’s attention.

What it looks like in practice

Open the network tab on a page with no interactive parts and you will see close to no JavaScript at all, just HTML and CSS. Open a page with a booking form and you will see one small script load, sized to that widget and nothing else. Nothing about how the page looks changes. What changes is how little the browser has to do before it can show you the words on the page, which is most of what a page needs to do anyway.