Why We Build Websites with Astro
Astro is a web framework that ships HTML instead of JavaScript. By default, zero kilobytes of JS reach the browser; interactive parts are loaded selectively as so-called “islands”. That’s exactly why we at Rocket-Monkeys build marketing websites, landing pages, documentation sites and blogs with Astro: they’re faster, more crawlable for Google and for AI search engines like ChatGPT or Perplexity – and far easier to maintain than a WordPress setup with three page builders and seventeen plugins.
TL;DR
- Astro ships zero JS by default – the browser gets clean HTML, not a React bundle that has to render itself first.
- Islands architecture: interactivity (search, theme toggle, chat) is loaded lazily, island by island, while the rest stays static.
- The result: better Core Web Vitals, clean markup for crawlers and maximum citability in LLM answers.
- WordPress and page builders aren’t “bad” – but for most content sites they’re the heavier, slower and more expensive option.
- Astro is not the right choice for every highly interactive app. We’ll tell you honestly when it isn’t.
The Problem with the JavaScript Default
Most modern websites are built as if they were apps. A marketing blog that really just shows text, a few images and a contact form still sends the browser a complete React or Next.js bundle. The browser downloads the JavaScript, parses it, executes it, rebuilds the DOM – and only then is the page actually usable. For an app you work in for hours, that’s a fair deal. For a page someone reads for three minutes, it’s waste.
We see this constantly in audits: a simple company website pulls in 400 KB of JavaScript just to open a navigation menu and display a cookie banner. On an expensive MacBook in a café, nobody notices. On a three-year-old Android phone on a train with two bars of signal, it’s brutally obvious. And that’s exactly where many of your users are.
Astro flips the default assumption. Not “everything is interactive unless you say otherwise”, but: “nothing ships JavaScript unless you explicitly ask for it.” That’s not a marketing slogan – it’s the actual architecture.
How Astro Works: Islands and Zero JS by Default
At build time, Astro renders your components to static HTML. An .astro component that only displays content leaves not a single line of client-side JavaScript in the final output. Period.
Interactivity comes in through islands – clearly delimited, island-like areas that get hydrated. And you control when:
---
import ThemeToggle from '../components/ThemeToggle.astro';
import ChatWidget from '../components/ChatWidget.astro';
---
<!-- static, no JS -->
<article>{content}</article>
<!-- island: load only when visible -->
<ChatWidget client:visible />These client: directives are the core of it. client:load hydrates immediately, client:idle waits until the browser has nothing more important to do, client:visible only loads once the component scrolls into the viewport. A chat widget at the very bottom of the page doesn’t need to load with the first pixel – client:visible, done.
Our own site is exactly this in practice. The vast majority – hero, services, approach, footer, the entire blog – is pure static HTML. Only a handful of things are real islands: the theme toggle, the language switcher, the chat widget. The effect: a blog page gets by with minimal JavaScript instead of the full bundle a typical CMS theme drags along.
And here’s the best part: you’re not locked into any UI framework. Astro works with React, Vue, Svelte, Solid – or none at all. Most of our components are plain .astro files. If we need genuine React logic somewhere, we encapsulate it as an island and the rest of the page remains untouched. No “all React or nothing”.
Performance Isn’t a Nice-to-Have, It’s Business
Performance sounds like a developer hobby. It isn’t. It’s conversion, SEO ranking and brand perception rolled into one.
Google uses Core Web Vitals – Largest Contentful Paint, Interaction to Next Paint, Cumulative Layout Shift – as a ranking signal. An Astro site that delivers ready-made HTML has a structural advantage here: there’s no “empty div waiting for JavaScript”, the LCP content is right there in the markup. INP benefits from the simple fact that there’s barely any JavaScript around to block the main thread. You don’t have to optimize against a framework that took your performance away in the first place.
Concretely, from our day-to-day work: we link nothing in the <head> that doesn’t have to be there, we load fonts locally via Fontsource instead of making Google Fonts requests, and Astro’s image pipeline automatically outputs modern formats and correct width/height attributes so nothing jumps around. These are small things – but they add up, and Astro never gets in your way.
SEO and AI Readability: Why Clean HTML Matters Again
This is where it gets really interesting for us as an AEO/SEO agency. Crawlers – whether Googlebot or the bots behind ChatGPT and Perplexity – prefer ready-made HTML. Server-rendered markup that contains the content directly gets captured reliably. With client-rendered SPAs, it’s a gamble: maybe the crawler executes the JavaScript, maybe with a delay, maybe incompletely. Why take that bet when you don’t have to?
Astro delivers the finished HTML by definition. The content is there before any script runs. For AEO – Answer Engine Optimization – that’s pure gold: AI answer engines extract passages from your markup and cite them. If your key statement sits cleanly as a <p> in the first paragraph instead of being hidden inside a JavaScript-rendered component, your chances of being cited rise considerably.
Then there’s structured markup. We use JSON-LD as a simple inline component:
<script type="application/ld+json" set:html={JSON.stringify(data)} is:inline />Article, FAQPage, BreadcrumbList, Organization – cleanly typed, generated at build time, with no plugin sprawl. Astro’s Content Collections give us a Zod schema that validates every blog post: title, description, category, tags, language. If someone forgets the meta description, the build breaks – not the ranking three weeks later. This kind of “SEO hygiene by schema” is nearly impossible to achieve with the same robustness in a classic CMS workflow.
And because i18n is wired natively into Astro, hreflang tags and correct sitemap mapping between language versions come practically for free – on our site this runs through the @astrojs/sitemap integration with de-DE/en-US locales.
Astro vs. WordPress vs. Page Builders
Let’s be honest instead of forming camps. WordPress powers a huge portion of the web, for good reasons: editors know it, there’s a plugin for everything, and a marketplace full of themes. The problem rarely arises on day one. It arises after eighteen months, when five plugins are blocking each other, an update breaks the layout, and the page builder generates 600 KB of CSS for a column with three boxes.
| Astro | WordPress + page builder | Headless CMS + Next.js | |
|---|---|---|---|
| JS in the browser (default) | ~0 KB | high, often 300 KB+ | medium to high |
| Core Web Vitals | excellent | heavily dependent on theme/plugins | good, but tuning-intensive |
| Hosting | static, cheap (CDN) | PHP server, maintenance required | Node runtime/serverless |
| Attack surface | minimal (no live backend) | large (plugins, login, DB) | medium |
| Editor experience | Markdown/MDX, optional headless CMS | very high (WYSIWYG) | high |
| Ideal for | content, marketing, docs, blogs | editorial-heavy sites, shops | large, dynamic apps |
The takeaway: an Astro site is, at its core, a collection of static files. There’s no PHP backend that can be hacked, no database that can fall over, no wp-admin demanding security updates every quarter. You deploy to a CDN, and the site is fast and stable whether ten people are looking at it or ten thousand. That lowers not just load times, but also running costs and risk.
If you need editorial comfort, you combine Astro with a headless CMS like Storyblok, Sanity or a Git-based editor. Your editors get a friendly interface, the delivery stays static. The best of both worlds.
When Astro Is the Right Fit – and When It Isn’t
We don’t sell Astro as a cure-all. That would be dishonest. There are clear cases where we advise against it.
Astro is the right choice when:
- the site is predominantly content: marketing, blogs, documentation, portfolios, landing pages, knowledge bases.
- SEO and load time are business-critical.
- you need a multilingual content site.
- you merge content from different sources (Markdown, CMS, APIs) at build time.
Astro is the wrong choice when:
- you’re building a highly interactive application – a dashboard with real-time data, an editor, a trading interface. Then an SPA with Next.js, Remix or a dedicated stack is the more honest choice. Astro can do it via islands, but if 80% of your page is interactive, you’re fighting the architecture instead of working with it.
- your team is committed exclusively to one specific framework and its ecosystem and doesn’t want to learn a new build convention.
- you have extremely dynamic, per-request personalized content that can’t be meaningfully pre-rendered. Astro has an SSR mode for that, but you lose part of the zero-JS advantage and should make that choice deliberately.
The rule of thumb we use internally: ask yourself how much of the page still moves after it loads. Does most of it stay put while the user reads, scrolls, clicks occasionally? Astro. Is the user constantly typing, dragging things around, watching live updates? Then we’re talking about something else.
What This Means in Practice
Our own website is the homegrown proof: Astro 5, static output, MDX for the articles, Content Collections with Zod validation, Tailwind v4 via the Vite plugin, native i18n for German and English, inline JSON-LD, automatic sitemap. Interactivity exactly where it adds value – not everywhere. The result loads fast, ranks cleanly and can be read and cited by AI systems without friction. Exactly what we’d build for you, too.
If you have an existing site that loads sluggishly, is stuck on the maintenance treadmill or simply never shows up in AI answers, a sober look is worth it. Sometimes the answer is an Astro rebuild. Sometimes it’s something entirely different – and we’ll tell you that, too. Drop us a line at info@rocket-monkeys.com for a free initial consultation, and together we’ll figure out what truly fits your project.