Astro: Ship Less JavaScript on Content Sites
A marketing site does not need a hydrated framework on every page. Islands make that an architecture, not a compromise.
A marketing site does not need a JavaScript framework hydrating every page. Most of what it renders is text, images and links — content that was solved before frameworks existed and does not benefit from being re-solved at runtime on the visitor's phone.
Astro's contribution is making that a real architecture rather than a compromise you apologise for.
Islands, briefly
Pages render to HTML at build time. Interactive components — the parts that genuinely need JavaScript — are marked explicitly and hydrate individually:
---
import Nav from '../components/Nav.astro' // zero JS
import BookingForm from '../components/Form.jsx' // interactive
---
<Nav />
<article>...</article>
<BookingForm client:visible />client:visible hydrates the form when it scrolls into view. Everything else ships as HTML with no framework payload at all.
The directive is the good design decision: interactivity is opt-in and visible in the code, so shipping JavaScript is a choice you make deliberately rather than a default you inherit.
Where it fits my work
Content-led sites where most pages are static and a few components are interactive — a services page with a booking form, a catalog with a filter, a blog with a search box. Being able to use React, Vue or Svelte components per island also means you can bring existing components without rewriting them.
Where it does not fit: applications. An admin dashboard is interactive on every screen, and fighting a static-first framework to build one is effort spent in the wrong place. Use a normal SPA.
The honest comparison
For a small brochure site, plain HTML and a little CSS is still the right answer and needs no build step at all.
Astro earns its place when there is enough content to want components, layouts and a content collection — but not enough interactivity to justify a full client-side application. That middle ground is where a lot of client work sits.
Why performance follows automatically
The fastest JavaScript is the JavaScript you did not send. Static-first means the default outcome is good Core Web Vitals rather than a number you claw back later with optimisation work.
Starting from a fast baseline is much cheaper than optimising a slow one, and it is the part of framework choice that shows up in a client's analytics.
Resources
- Repo: withastro/astro
- Docs: docs.astro.build
- Video walkthroughs: YouTube: Astro islands
- Related: Core Web Vitals on an image-heavy site
Need this built properly?
I build secure, fast, bilingual platforms for clients across Egypt, Saudi Arabia, the UAE and Kuwait.
