When I built the marketing site for Spacloudy, I started on Next.js. It’s what I knew, and it’s a fine tool. But a few months in, I moved the whole thing to Astro — and the pages got faster for a reason that’s almost embarrassing in hindsight.
The problem with the default
A marketing site is mostly content: headings, paragraphs, a few images, some links. None of it changes after the page loads. Yet a typical React-based marketing site ships the entire framework runtime to the browser to render text that could have been plain HTML.
You’re sending a JavaScript engine to display a brochure.
What Astro does differently
Astro renders your components to HTML at build time and ships zero JavaScript by default. You opt in to interactivity per component — an “island” — only where you actually need it. The result, for a content page, is HTML and CSS and nothing else on the main thread.
For Spacloudy’s marketing pages, that meant faster loads on exactly the pages that drive signups, with no loss of authoring comfort: I still write components, still use TypeScript, still get a great dev experience.
The rule I use now
Don’t ship a JavaScript framework to render content that doesn’t change.
It’s simple, and it decides a surprising amount:
- Marketing site, blog, docs, portfolio? Astro. Content-first, islands where needed.
- App behind a login with lots of state? Nuxt or Next. The interactivity earns the runtime.
This very portfolio is the rule in practice — it’s built on Astro, and most pages ship no client JavaScript at all. The few interactive bits (the theme toggle, the mobile menu, scroll reveals) are tiny, scoped scripts, not a framework.
The lesson
Reach for the heavy tool when the problem is heavy. For everything else — and “everything else” is a lot of the web — render the HTML and stop there. Your users’ phones will thank you.