Astro or Next.js for a corporate site?
Why one framework is measurably faster on a content-heavy corporate site, what that means for SEO, and the point at which you should switch to Next.js.
This site is built with Astro. That is not a statement of allegiance but the result of a constraint — and explaining the constraint is more useful than the conclusion.
The question is not “which is better”
Next.js is mature, powerful and has a huge ecosystem. Astro is younger and narrower in scope. Compared in the abstract, neither fact helps. The right question is:
How much JavaScript genuinely needs to run on this page?
On a corporate site — home, service pages, blog, contact — the answer is usually “almost none”. A menu opens and closes, there are a few animations, a form gets submitted. Everything else is text.
What Astro does
Astro renders pages to HTML at build time and ships zero JavaScript by default. If you want a component to run in the browser you say so explicitly (client:load, client:visible). JavaScript enters the page because it was asked for, not because it was forgotten.
With the App Router and server components, Next.js can get close to a similar result — but the React runtime and hydration infrastructure still land in the bundle. On a typical corporate site the gap is around 60–120 KB of compressed JavaScript.
That gap shows up in three places:
- INP (interaction latency) — the main thread is idle, so clicks are answered immediately.
- Low-end mobile — a large share of organic traffic is mobile, and JavaScript parse cost is genuinely felt there.
- Hosting cost — static files are served from a CDN with no server running.
Actual measurements
Building the same corporate site twice and measuring (4G, mid-range Android, average of three runs):
| Metric | Astro (static) | Next.js (App Router, SSG) |
|---|---|---|
| JS shipped (gzip) | ~9 KB | ~86 KB |
| LCP | 1.1 s | 1.6 s |
| INP | 42 ms | 118 ms |
| Total requests | 14 | 27 |
The numbers vary by project and content; what matters is not the absolute values but the order of magnitude. We share them not to make Next.js look bad, but to show the difference is not at noise level.
What this means for SEO
Claiming “Astro improves rankings” would be wrong. Google ranks on content and authority. But two indirect effects are real.
Crawl efficiency. Googlebot receives HTML and sees the content immediately; it does not wait in the JavaScript rendering queue. On a site with many pages, that affects how quickly new pages get indexed.
Core Web Vitals. Page experience signals are not a decisive ranking factor, but they can act as a tiebreaker at equal content quality. More importantly: a slow page directly lowers conversion rate, and that costs you money regardless of SEO.
Where Astro stops being the answer
Astro is not the right answer everywhere. We move to Next.js when there is:
- Authenticated areas. A per-user dashboard, subscription management, session state.
- Frequently changing dynamic data. Stock levels, pricing, live dashboards.
- Complex client state. Multi-step configurators, drag-and-drop interfaces, real-time collaboration.
- A large existing React codebase. When the cost of a rewrite exceeds the gain.
On an e-commerce project the split we usually land on is: marketing pages and blog in Astro, product and checkout in Next.js. Both applications are served under the same domain on different paths.
Blog tooling
On most corporate sites the blog is the actual engine of SEO, and here Astro’s content collections are noticeably comfortable:
// src/content.config.ts
const blog = defineCollection({
loader: glob({ pattern: '**/*.md', base: './src/content/blog' }),
schema: z.object({
title: z.string(),
publishedAt: z.coerce.date(),
tags: z.array(z.string()).default([]),
}),
});The schema is validated at build time: forget publishedAt on a post and the site does not build. Broken content never reaches production. For teams coming from WordPress this is unfamiliar and quickly becomes indispensable.
The cost side
Hosting static output on Cloudflare Pages makes monthly infrastructure cost effectively zero: no server, no scaling, unmetered bandwidth. Running Next.js with server-side features means paying for a runtime.
For a corporate site the annual difference may look small — but the real saving is not on the invoice, it is in maintenance load. A running server is a server that has to be monitored and patched.
Our rule
In one sentence: if the page’s job is to explain the business, Astro; if the page’s job is to run an application, Next.js.
If a site contains both, we use both. The point is not loyalty to a framework but building each page with the tool that fits its job.
If you are not sure which side your site falls on, let us look together in a short call — we will measure your current site and give you a reasoned recommendation.
