Astro
Multi-framework, content-first, ships zero JS by default. The default for SEO-heavy sites.
VISIT ASTROKey takeaway: When the content is the product and nothing about the brief is application-shaped, this is where I start, and I would need a specific reason to pick anything else. The comparison that matters is against Next.js: Astro ships less JavaScript, costs less to run, and is faster to build content routes in, while Next.js wins the moment auth, dashboards, or real-time enter the picture.
Quick facts
- LanguageTypeScript
- CategoryMulti-framework
- LicenseMIT
- Created2021
- GitHub stars49.5k
- Statusactive
Templating: Astro JSX Vue Svelte Solid Markdown MDX
What it is
Astro is the framework I reach for first when content is the protagonist. It ships zero client-side JavaScript by default, supports every major UI framework as island components, and has a Content Layer plus image pipeline that handles the boring 80% of a content site without ceremony. I run a 91,000-page site on it (Deluxe Astrology) and it is the most production-tested framework I have used at that scale.
Best for
- Marketing sites and landing pages where Core Web Vitals matter
- Documentation, blogs, and content hubs
- Programmatic SEO at scale (HostList: 25k pages, Deluxe Astrology: 91k pages)
- Multi-framework teams sharing a single static site
- Migration off WordPress when content is structured cleanly
When not to pick it
Skip Astro if your site is application-first, auth, dashboards, real-time, complex interactivity. Server Islands and the View Transitions API closed the gap a lot in 2025-2026, but Next.js or Remix is still the better tool for application-shape briefs.
My take
Astro is the framework most teams should default to in 2026 unless they have a specific reason not to. It scales from a 5-page brochure to a 90k-page directory without changing architecture. The Content Layer feature shipped in 2024 made it genuinely cheaper to run than self-hosted WordPress for the same content size.
Islands, and what zero JavaScript by default actually buys
Every Astro component renders to HTML at build time and ships no client runtime unless you explicitly ask for one with a client directive. In practice a marketing page or an article route sends HTML and CSS and nothing else, so Largest Contentful Paint is bounded by your images rather than by hydration, and Interaction to Next Paint stops being a problem on content routes because there is no main-thread work left to block. When you do need interactivity you opt in per component, and you can use React, Vue, Svelte, or Solid inside the same project, which is genuinely useful when a team already has components in more than one framework. The discipline this enforces is the real value: adding client JavaScript becomes a visible decision in code review rather than the invisible default, so pages stay light because making them heavy takes effort.
What breaks at 90,000 pages
I run a site of roughly 91,000 pages on Astro, and the honest report is that the architecture holds but the build does not stay free. Full builds move from seconds into many minutes, memory becomes the limiting factor before CPU does, and the image pipeline is usually the thing that pushes a CI runner over its ceiling. The fixes are known rather than mysterious: pre-optimise images outside the build and serve them from storage, split locales or sections into separate builds, and use on-demand rendering for the long tail nobody crawls daily. The content layer caches loaded data between runs, which helps, but every page still renders every time, and a true incremental build that touches only changed content is the feature I would most like to see. If your catalogue is enormous and changes constantly, plan the build strategy on day one.
Frequently asked questions
Is Astro better than Next.js for SEO?
For content sites, usually yes, and not because of anything Astro does to your metadata. It is faster by default, so Core Web Vitals are easier to pass, and static HTML removes the class of rendering bugs that hurt crawling. Next.js can match it, but you have to work continuously at keeping the client bundle small.
Can Astro handle tens of thousands of pages?
Yes. I run a 91,000-page site and a 25,000-page directory on it. Build time and memory become the constraint long before correctness does, so budget for pre-optimised images, builds split by section or locale, and on-demand rendering for pages that rarely change. The routing and content model itself scales fine.
Does Astro support React components?
Yes, along with Vue, Svelte, Solid, Preact, and Alpine, and you can mix them in one project. Components render to HTML by default; adding a client directive hydrates that single component and ships only its framework runtime. That is why teams migrating from React rarely have to rewrite their interactive pieces.
Links
Compare Astro side-by-side
Similar tools you should also consider
If Astro is your pick, the next conversation is short
The 30-min call is where your project gets a real architecture, an SEO transport plan, and a price range you can take to your team. Describe your site, your timeline, your existing content. I tell you whether Astro is genuinely the right call for you, and what the build actually looks like.