Astro vs React for a site that is mostly content
A marketing site shipped as a React SPA is a tax you pay on every page load. The page is 90% text and images, but the visitor still downloads a framework, waits for it to boot, and then gets the content that could have been there from the first byte. Most of the time the reason it was built that way is habit, not need.
The SPA tax
When a mostly-static site ships as a single-page React app, the cost shows up in a few places at once.
- Bundle size: the framework, the router, and your components all download before the first meaningful paint.
- Hydration: the browser rebuilds on the client what the server could have sent as finished HTML.
- SEO and time to first paint: crawlers and slow phones both wait on JavaScript to see content that was never going to change.
None of that buys you anything on a page whose job is to render an article and a contact button. You are paying for interactivity you do not use.
What Astro does differently
Astro renders your pages to HTML at build time and ships zero JavaScript by default. The text, the images, the layout all arrive as plain HTML. There is nothing to hydrate because there is nothing dynamic on the page yet.
When a piece of the page does need to be interactive, you opt in with an island. A search box, a pricing toggle, a comment widget: you mark that one component to hydrate, and only that component ships JavaScript. The rest of the page stays static. You get to use React (or Preact, or Svelte) for the interactive bits without paying for it everywhere else.
The line I actually use
The question I ask before starting is simple: how much of this page is genuinely stateful?
If the answer is “almost none, it’s content with a form or two,” Astro wins easily. Blogs, marketing sites, docs, portfolios, landing pages. The whole JAMstack shape.
If the answer is “most of it, the page is an app,” then the SPA model earns its weight and Astro’s islands start to feel like fighting the grain. A dashboard behind a login, an editor, anything where the user spends minutes interacting rather than seconds reading.
Most sites people call “apps” are actually the first kind wearing the second kind’s stack.
Where React still wins
This is not an argument against React. I reach for it, or Preact for a lighter footprint, whenever a page is driven by client state that changes constantly and gets read all over the tree. A live cart, a multi-step flow, a collaborative view.
The point is not “Astro good, React bad.” It is that the framework should match how dynamic the page really is. Ship a static site as static HTML, add islands where the interactivity actually lives, and reach for a full SPA when the page is genuinely an app. Decide by the page, not by habit.