Astro for Content-Driven SaaS Marketing Sites: When It Beats Next.js
Most SaaS companies run two different websites under one brand: the product people log into and the marketing site that gets them to sign up. The product is usually React, often Next.js. The marketing site tends to end up on Next.js as well, mostly because the team already lives there. The Astro vs Next.js question is really a question about that default: for landing pages, a blog, and docs, is an application framework still the right tool? Often it is not. Astro was built for exactly this workload. There is also one common setup where staying on Next.js is clearly the better call, so the decision is worth working through properly rather than settling it by habit.
What Astro Does Differently
Astro starts from the assumption that a content page should be HTML. Pages render to static markup at build time or on the server, and JavaScript only ships for components you explicitly mark as interactive. Those components become islands: small, isolated widgets that hydrate independently of each other. A pricing page with a currency toggle ships the code for the toggle and nothing else. A blog post with no interactivity ships no JavaScript at all.
Next.js approaches the same page from the other direction. It is an application framework, and even with React Server Components in the App Router, every page loads the React runtime and the client router so the tree can hydrate and navigate on the client. Depending on your setup that is roughly 80 to 100 KB of gzipped JavaScript before any of your own code runs, on every page, including the ones that are just text and images.
For a dashboard, the runtime earns its place. For an article that a prospect reads once on a train, it is overhead the visitor pays for and never uses.
Astro vs Next.js: Where Astro Wins for Marketing Sites
The performance argument is the loudest one, and it is mostly true. A plain Astro build tends to land mobile Lighthouse scores in the high 90s without any tuning. You can get a Next.js site to similar numbers, and we have done it, but you get there through work: auditing client components, trimming dependencies, wrangling image loading, and re-checking after every feature. Our guide to Next.js performance optimization describes that workflow in detail, and the honest summary is that it is a workflow. Astro gives you a similar result as the default state.
The quieter advantage is the content workflow. Astro's content collections let you define a schema for your frontmatter, validate every file at build time, and query posts through a typed API. Broken dates and missing fields fail the build instead of shipping. In Next.js, Markdown and MDX support is assembled by hand from packages and glue code, and the community tooling that filled this gap has had a rocky maintenance history. A team publishing four posts a month feels this difference every week.
Bundle size follows from the architecture, so it barely needs its own argument. Less JavaScript shipped also means fewer hydration mismatches, fewer error reports from ancient Android browsers, and less code to keep current.
Many teams also miss that choosing Astro does not mean leaving React. Islands can be React components, so an existing design system carries over. You write the page shell in Astro templates and mount your signup form or interactive calculator as a React island where it belongs.
A short comparison for the marketing site case specifically:
| Astro | Next.js | |
|---|---|---|
| JavaScript on a plain content page | None by default | React runtime plus router on every page |
| Lighthouse scores | High without effort | High with ongoing effort |
| Markdown and MDX | Built in, schema validated | Manual setup |
| Shared login state with your app | Possible but awkward | Native |
| Team overhead | Second framework to maintain | One framework everywhere |
Where Next.js Is Still the Right Call
The strongest case for Next.js has nothing to do with rendering speed. It is the shared session.
If your marketing pages and your application live on one domain and the navbar changes when someone is logged in, if pricing pages show personalized CTAs, if you run experiments through the same feature flag system the product uses, then your marketing site is an extension of the product rather than a separate site. Keeping it in the same Next.js app means components, auth, and analytics all work without ceremony.
You can rebuild that in Astro. Server islands can render personalized fragments, and cookies can be read across subdomains. But every one of those bridges is code you write and maintain across a framework boundary, and the complexity lands exactly where Astro was supposed to make things simpler. When we review a setup like this in a tech stack strategy engagement, our advice is usually blunt: a logged-in navbar is a sign you should stay where you are.
The second reason is team capacity. Astro is a second toolchain, with a second config to understand and a second upgrade cycle to schedule. A five-person team that ships product features with Next.js may be better off accepting a slower blog than splitting attention across two frameworks. Framework sprawl has a cost even when each framework is individually excellent, a theme we also cover in our comparison of React frameworks.
What a Migration Costs
For teams that do fit the Astro profile, the migration is smaller than most expect, because marketing sites are mostly content and content ports well.
| Scope | Typical effort |
|---|---|
| Landing pages plus a blog, up to about 50 pages | 1 to 2 weeks |
| Multi-language site with docs, 100 to 300 pages | 3 to 5 weeks |
| Marketing pages tangled into the product app | Often not worth extracting; carve out truly static pages only |
Markdown and MDX content usually moves with light frontmatter changes. React components can be reused as islands rather than rewritten. The time goes into the unglamorous edges: redirect rules that lived in middleware, internationalized routing, Open Graph image generation, consent and analytics scripts, and form endpoints. Budget most of your schedule for those, not for pages.
Plan the SEO mechanics the way you would for any replatforming. Keep URLs stable where possible, map 301 redirects where not, and diff the sitemap before and after. Done carefully, rankings should not notice the switch, and the Core Web Vitals improvements can help them over the following months.
The Performance Delta You Can Expect
Typical results, with the caveat that every site starts from a different baseline. On content pages, shipped JavaScript drops from somewhere between 90 and 250 KB gzipped to near zero, since only the islands remain. Mobile LCP commonly improves by several hundred milliseconds once render-blocking scripts disappear, more if the old site hydrated large component trees. Interaction metrics like INP improve because there is very little JavaScript left to occupy the main thread. Mobile Lighthouse scores that sat in the 60s or 70s tend to land in the 90s.
Two honest qualifiers belong next to those numbers. If your Next.js marketing site already scores above 95 on mobile, Astro buys you little that visitors will feel, and the migration is hard to justify on performance alone. And Core Web Vitals are one ranking input among many, so faster pages will not rescue thin content. The gains are real, but they compound with good content rather than replacing it.
How to Decide
Choose Astro when the marketing site is content heavy, has no logged-in state, deploys separately from the product, and the team can absorb one more tool. Stay on Next.js when marketing and product share a session or a domain, when personalization drives the funnel, or when the team is too small to split its attention. If you are picking a stack for a new project rather than weighing a migration, our guide to choosing a Next.js framework setup covers that adjacent decision.
The pattern we see most often in practice is a hybrid. The product stays on Next.js, the marketing site and blog move to Astro on their own deploy, and both share a component library. Each tool does the job it was designed for, which is less satisfying as an ideology and more satisfying in the Lighthouse report.
FAQ
Can I use my existing React components in Astro?
Yes. Astro renders React, Vue, Svelte, and Solid components as islands. Most teams reuse their design system directly and only rewrite components that were entangled with application state.
Does Astro work with a headless CMS?
Yes. The content layer introduced in Astro 5 loads entries from APIs and CMS backends through the same typed collections used for local Markdown files, so editors keep their existing workflow.
Is Astro suitable for the application itself?
Usually not. Once most pages sit behind a login and carry state, you are building an application, and an application framework like Next.js is the better fit. Astro's strength is the content perimeter around the product.
Where Wolf-Tech Fits
We help SaaS teams make framework decisions like this one with measurements instead of advocacy, as part of our web application development work. Sometimes that means a migration plan with a redirect map and a two-week schedule. Just as often it means telling a team their current setup is fine and the afternoon is better spent elsewhere.
If you are weighing Astro vs Next.js for your marketing site, write to us at hello@wolf-tech.io or visit wolf-tech.io. We will look at what you have and give you a plain answer.