The wrong question

People ask us “which framework is better, Astro or Next.js?” That is the wrong question. They are both excellent. They are built for different things.

Next.js is incredible for web applications — dashboards, SaaS products, anything with authentication, real-time data, and dozens of interactive views. Astro is incredible for content-driven websites — marketing pages, portfolios, blogs, documentation, landing pages.

The right question is: what are you building?

For roughly nine out of ten small business websites, the answer is a content-driven marketing site. And for that, Astro wins. Let’s get specific about why.

The hydration tax

This is the core difference, and it is worth understanding.

Next.js is built on React. Even when you use Server Components, the browser still has to download the React runtime, parse it, and have it ready. For an interactive application this is a fair trade. For a five-page brochure site it is overhead you carry for no benefit.

Astro does not require anything on the client. It renders pages to static HTML at build time. The browser receives HTML and CSS. That is the whole payload for most pages. There is no runtime to download, no hydration step, no virtual DOM waiting in the wings.

On a mid-range phone, this is the difference between a page that appears in 600 milliseconds and one that appears in 2.5 seconds. That gap is the React runtime doing work the page never asked for.

SSR vs SSG

Next.js does server-side rendering by default. Every request hits a Node server, which renders the page and sends it back. This is powerful — you can show personalized data, run database queries, render fresh content on every load. It also means you are running and paying for a server, and every page load depends on that server staying healthy.

Astro does static site generation by default. Pages are rendered once at build time into plain HTML files, then served from a CDN edge node milliseconds from the visitor. No server to keep alive. No cold starts. No scaling worries. You can opt into server-side rendering when a specific page needs it, but it is not the default.

For a business site that changes weekly, not per-request, static is the right default. It is faster, cheaper, and more resilient.

Bundle sizes, with numbers

Let’s put real numbers on this. We measured two equivalent five-page marketing sites, same design, same content.

Total page weight including CSS was roughly 60KB for Astro and 280KB for the Next build. Same visual result. One loads in under a second on a cheap phone. The other does not.

SEO implications

Both frameworks can produce SEO-friendly sites. Both let you set meta tags, generate sitemaps, handle canonical URLs. But the output is not equally easy for search engines.

Astro emits clean static HTML. Googlebot reads it directly, no execution required. There are no hydration mismatches to confuse the crawler. There is no client-side routing that has to be replayed. The HTML that ranks is the HTML that ships.

Next.js with heavy client-side interactivity can still render correctly for crawlers, but you are relying on the framework to do the right thing, and you occasionally run into hydration warnings, dynamic routes that need careful configuration, and metadata that has to be set up through a specific API. It works. It is just more moving parts.

Developer experience and tooling

Next.js has the larger community and more third-party components, more tutorials, a bigger hiring pool. If you need a complex component library, Next.js paired with shadcn/ui is hard to beat. If your team already knows React deeply, Next.js is a comfortable choice.

Astro is simpler. You write .astro files, which are HTML templates with a sprinkle of component logic and optional interactive islands. No hooks. No global state management. No useEffect puzzles. For a marketing site, that simplicity is a feature, not a limitation. It means a smaller surface area for bugs, faster builds, and code that a future developer can actually read.

A diagram comparing Astro's static output against Next.js's React runtime overhead

Astro also has a trick Next.js does not: you can use React, Vue, Svelte, or Solid components inside an Astro page, and only the ones marked as islands ship JavaScript. So if you have one interactive widget you love that is written in React, you can drop it into an Astro page and the rest of the page stays static.

Maintenance over three years

Think past launch day. A Next.js site has a build pipeline, a server to host, dependency updates for React and a long tail of packages, and security patches. A static Astro site is a folder of HTML files on a CDN. There is almost nothing to break. When a dependency needs updating, you update it and redeploy. There is no runtime server to monitor.

For a small business without a dev team on staff, this matters more than people realize. The cheapest site to maintain is the one with the fewest moving parts.

When you should pick Next.js anyway

To be fair, there are cases where Next.js is the right call. You should reach for it when:

None of those describe the typical small business site. If they describe yours, use Next.js without guilt.

Our verdict

If you are building a web app: Next.js. If you are building a marketing or business website: Astro.

We build exclusively with Astro because every client we work with falls in the second category. We are not religious about it. If a project genuinely needs a full client-side framework, we reach for the right tool. But we have yet to meet a small business site that did.


Want a fast, hand-built site on a stack that fits the job? See our pricing or tell us what you are building.