Evaluating Astro for Content-Driven Sites
TL;DR: Astro ships zero JavaScript by default and hydrates only the interactive islands you opt into — so content sites come out fast almost for free, with whatever component framework you like (React, Vue, Svelte, side by side). It is emphatically not the tool for app-like, deeply interactive products. The most useful output of the evaluation wasn’t a feature list; it was a boundary. Verdict: 🟡 worth pursuing — adopt it deliberately, pending stack-fit, security, and at-scale checks. (This portfolio runs on it, so I had skin in the game.)
🎯 The Habit Worth Questioning
The frontend default had quietly become “reach for a full React/Next app no matter how interactive the page actually is.” For content — blogs, marketing, microsites, docs — that means shipping a lot of JavaScript to do very little. Astro inverts the default: render to HTML, hydrate only what truly needs it. That’s a big enough idea to deserve a real look rather than a hot take.
🏝️ Islands Architecture, Concretely
The page is static HTML; interactivity is islands of hydration in a sea of zero-JS content.
flowchart TD
A["Astro page<br/>(static HTML, 0 JS)"] --> B["Header island<br/>(React) — client:idle"]
A --> C["Static content<br/>(no JS shipped)"]
A --> D["Search island<br/>(Vue) — client:visible"]
A --> E["Static footer<br/>(no JS shipped)"]
You decide when each island wakes up, which is where the performance comes from:
| Directive | Hydrates… |
|---|---|
client:load | Immediately on load |
client:idle | When the main thread goes idle |
client:visible | When it scrolls into view |
client:media | When a media query matches |
Everything else ships as pure HTML and CSS. You get excellent Core Web Vitals without the manual tuning that usually buys them.
✅ What’s Genuinely Good
- Performance by default. A no-JS baseline means fast LCP and almost no unused script — the optimization is the architecture, not an afterthought.
- Framework-agnostic. React, Vue, Svelte, and Solid components coexist in one project, which makes migrations dramatically less scary.
- Content Collections. Typed, schema-validated Markdown/MDX with genuinely good DX — this blog is built on exactly that.
- View Transitions. SPA-like navigation without an SPA’s weight.
- A small mental model. The framework gets out of the way, and the build is fast.
⚠️ The Boundary That Matters
The single most important conclusion was a limit, not a feature:
Astro is built for content-driven sites — not interactive web apps.
If your product is dashboard-heavy, stateful, or real-time — if it behaves more like an application than a document — a full app framework is the right answer. Astro can host islands of that interactivity, but bending the architecture to build an SPA inside it is swimming upstream, and you’ll feel the current.
🧪 Before Trusting It on Client Work
The verdict came with homework, and it’s the right homework:
- Stack fit — test Astro against the existing tech stack and integration points, not a toy.
- Security & compliance — confirm it clears the bar enterprise clients hold you to.
- Performance at scale — validate large content sets and build times, where SSGs sometimes struggle.
Verdict
🟡 Worth pursuing. For the content-site half of agency work, Astro hands you the performance most teams pay for by hand. The move is a real project trial with the security and scale boxes ticked: adopt it where the page is fundamentally a document, and keep the app frameworks for the things that are fundamentally apps. Knowing which is which is most of the skill.