Building websites isn't something I do very often — especially when your focus is engineering and architecture — but with Rush CMS my workload shifted a bit, and it gave me a lot of room to think about the best structure I've found for my workflow when it comes to a Headless CMS. If you still build sites, or manage people who do, this article might be useful.
I'll say upfront: I'm not going to try to convert you — zero framework-as-religion debate here! What I've got to show you is boring, but useful: today I run 10 client sites on Astro, the vast majority served by Rush CMS, from my own rafhael.pro to CTB Brasil's homepage with 30+ photos (and a PageSpeed Insights score of 97), plus a construction company site, a school, a bakery, a pharmacy... It's a real portfolio, in production, paying the bills. This post is the accounting of what Astro buys me in that scenario — and at the end I also explain why it's not the right tool.
The problem Astro solves for me
Most of what I ship is what the Astro team honestly calls "content-driven": brochure sites, landing pages, blogs, portfolios. These are sites where the content needs to reach the reader fast — not logged-in dashboards or social networks — so they need to be fast, sometimes faster than they are pretty.
The problem is that the industry spent years pushing web app tooling to solve website problems. Next.js and Nuxt are good for complex apps with global state and authenticated areas. But their SPA model was designed to render the whole site on the client, with SSR bolted on later, mostly to patch performance. For a landing page or site whose only job is to deliver the message and convert, shipping a React runtime on first load is worse than overkill: it's losing money.
Astro inverts that: it's server-first by default. Astro follows the same approach PHP, WordPress, Laravel and Rails have used for decades — except you don't need to learn a second server-side language, because it's all still HTML, CSS and JavaScript. Personal note: I personally despise the WordPress Dinosaur, and I don't want to flip every switch in the cockpit with Next.js for a landing page (thankfully, that's in my dark past). I want to deliver the best possible work in the most appropriate way possible. The first time I tried Astro, I felt like I was coming home — but with modern tooling.
What is Islands Architecture?
It's a pretty elegant idea, simple to explain, and it has a direct line to the performance bill: instead of hydrating the whole page in the browser, Astro renders everything as static HTML and isolates interactivity into "islands" that load JavaScript only when needed. In practice, in the case of Rush CMS, that means 90% of a brochure site (header, hero, copy, footer) ships as pure HTML, with zero client JS. If the page has a contact form or a carousel, only that component loads a script:
---// The .astro file renders on the server. Header, Hero and Footer// become pure HTML: zero JavaScript shipped to the client.
import Header from '../components/header.astro'import Hero from '../components/hero.astro'import ContactForm from '../components/contact-form.ts'import Footer from '../components/footer.astro'---
<Header /><Hero /><!-- JS only loads when the component enters the viewport --><ContactForm client:visible /><Footer />The client:visible directive is the detail that matters: the form only downloads and runs its js when the user scrolls to it. On a landing page, that usually means the JS is never downloaded, because the CTA already converted before that.
So, the numbers? Give me the numbers!
According to the official documentation, Astro can deliver a site 40% faster, with 90% less JS than (provavly) Next.js.
In the article Why Speed Matters, the impact each project can have by making its structure and site faster is broken down — with real cases — regardless of the language used. It has cases like "Every 100ms faster, Mobify recorded 1% more conversions", "Pinterest cut load time by 40% and gained 15% more sign-ups", and "AutoAnything got 50% faster and sold 12% more".
You can do this with React, Next.js or any framework of the moment. But when it comes to sites, why would I reinvent the wheel if I already have in hand a framework that's extremely easy to use and delivers an incredible result with so little? Performance has measurable financial impact, and Astro's architecture makes performance the default instead of a constant battle.
In my most recent case, the CTB Brasil site (link at the top of the post), a homepage with 30+ photos, I measured 97 on mobile Lighthouse — with over thirty images that would normally be a performance massacre — without having to do anything special: astro:assets, lazy loading, automatic WebP, no sweat!
It all comes down to flexibility
This part I like, a lot! Astro is UI-agnostic. If you need to, feel free to use React, Vue, Svelte, Solid, or whatever in your islands. In practice that means if tomorrow I decide Svelte handles a specific component better, or I inherit a Vue component from an old project, I don't rewrite the site.
Astro + Bun
If Astro solves client-side performance, Bun attacks the other side of the bill: build time and CI/CD. Astro supports Bun officially, but I like to use this approach:
bun create astroLet me be specific in my skepticism again: Bun's speed gains are real and well-documented for dependency installs and cold starts, but the exact figure depends on your project and your runner. I use the combination daily and the gain shows up mostly where it hurts most — the pipeline that runs on every push.
Where Astro is NOT the answer
You probably already know this: I use Astro for sites and landing pages. For anything else, I reach for the beautiful Svelte or the ugly React (ugly, yes, but it pays the bills). Trying to force Astro into the UI of systems, platforms, and so on feels like a big shot in the foot to me — not impossible, but limiting.
And you? Have you tried Astro when you needed to build some web page, or have you already delegated everything to the AI agent that loves a good Next.js?