Short version
Astro and Next.js solve different problems. Astro builds static HTML by default and sends very little JavaScript to the browser, a useful starting point for content-heavy websites. Next.js is a full React framework for applications with complex interactions, signed-in users and server logic. Sometimes neither is the right answer: a classic CMS stack remains a reasonable choice for a simple site whose owner needs a familiar dashboard. Choose for what the website needs to do, not for the framework's popularity.
Astro and Next.js solve different problems. If your website mainly publishes content, Astro gives you a lightweight starting point: static HTML and JavaScript only where you need it. If you are building an application with signed-in users and substantial server logic, Next.js is usually the more natural fit. And if you need a simple website with a familiar editing dashboard, a classic CMS stack still deserves a place on the shortlist.
The choice starts with what your website must do. A popular framework is not a project requirement.
What are Astro and Next.js designed for?
Both are frameworks for building websites, but they start at different ends.
Astro starts with content. By default, it renders pages to ordinary HTML during the build. Where you need interactivity, such as a search field or a map, you add an island that receives JavaScript. The rest of the page stays HTML and CSS. That gives content-heavy pages a good starting point for speed without having to remove an application layer afterward. Astro also lets you use React, Svelte or Vue components where they make sense; you are not tied to one UI library.
The Astro documentation describes that purpose directly:
“Astro is the web framework for building content-driven websites like blogs, marketing, and e-commerce.”
Next.js starts with the application. It builds on React, bringing together server rendering, API routes, Proxy (formerly Middleware) and patterns for authentication. Its documentation calls it “a React framework for building full-stack web applications.” An interactive application benefits from that integration. It also brings more decisions about hydration, caching and the runtime needed for server features.
This website runs on Astro 7 with Content Collections and content in Git. I chose that setup because the site has a lot of content, little complex interaction and demanding speed requirements. A website without a CMS explains how MDX and JSON files in Git work as its content layer.
What real websites measure: 69.8% vs. 33.9%
As of the July 2026 dataset, the HTTP Archive Tech Report shows 69.81% of 38,870 mobile Astro origins passing Core Web Vitals, compared with 33.89% for Next.js. That is a difference of about 35.92 percentage points. The 40,645 mobile Astro sites also listed in the report belong to the FCP population; they are not the denominator for the combined Core Web Vitals result.
In the same comparison, WordPress reached 49%, Gatsby 45% and Nuxt.js 28%. The whole percentages in the chart below are rounded down, including Astro at 69% and Next.js at 33%.
Mobile origins passing Core Web Vitals
HTTP Archive · July 2026 · mobile · worldwide
These are field measurements from the Chrome UX Report population, not a controlled laboratory comparison. The frameworks serve different kinds of websites, and the groups differ in size. Vercel acknowledges that distinction: Astro’s higher pass rates are real, but partly reflect the content-focused websites for which people choose it. The chart does not prove that a framework automatically makes every project fast.
The architecture does help. Astro sends no browser JavaScript for static components by default and hydrates only the interactive islands you opt into. Less JavaScript means less parsing and execution on a phone. An experienced team can achieve the same Core Web Vitals with Next.js, but needs to watch client components, hydration and bundle size deliberately.
I also measure the production sites in the portfolio monthly. As of September 2, 2026, the twelve other case sites had a median of 98.5/100 for their best mobile PageSpeed score in September through that date. The verifiable fastest LCP in those snapshots is 937 milliseconds. The earlier Dutch article quoted 923 milliseconds, but that value could not be traced back to the snapshots and was corrected.
These are lab measurements of real production sites, not bare demos or the field data in the chart above. Astro provides a lightweight foundation; image choices, fonts, external scripts and careful development still determine the result. The individual measurements are available in the case studies.
The third option framework comparisons often skip
Framework and CMS vendors tend to compare modern frontend stacks. For many small businesses, the classic route remains relevant: WordPress with a suitable theme and a limited number of plugins.
It is accessible. Install it, sign in and fill your pages. Features that require custom development in a modern stack may be available as ready-made plugins. You may also recognize the downside: postponed plugin updates, theme conflicts and a site that gets slower as more is added. A classic stack is not a bad choice. It is a commitment to regular maintenance.
Astro, Next.js and classic CMS stacks side by side
The more shared interaction and server logic your project needs, the further it moves from Astro’s static comfort zone.
| Criterion | Astro | Next.js | Classic CMS stack |
|---|---|---|---|
| Rendering | Static HTML by default; optional server rendering | Server rendering, static or hybrid | Server-side, inside the CMS |
| JavaScript footprint | Minimal by default; interactive islands opt in | React client components and hydration where needed | Depends on the theme and plugins |
| Best fit | Marketing websites, blogs, documentation | Web apps, dashboards, platforms | Simple sites that need to launch quickly |
| Interaction | Islands; shared application state needs planning | Integrated patterns for state, forms and real-time features | Plugins within the CMS ecosystem |
| Content management | Headless CMS such as Storyblok, or content in Git | Headless CMS or a custom backend | Built-in dashboard |
| Maintenance | Simple static hosting; dependencies still need updates | Dependencies, hosting and runtime for server features | Core, theme and plugin updates |
| Technical skills | Frontend development | Frontend and backend skills | Lower entry barrier; dashboard-based management |
| Hosting | Static hosting on a CDN, or runtime for server rendering | Static export, or runtime for server features | Hosting with a database |
Not sure which stack fits your plans? I can help weigh the trade-offs rather than start with a framework preference. The Astro website development service explains that approach.
Which framework fits each use case?
Marketing website or blog
Astro is usually my first choice here. Lots of pages, lots of content and little complex interaction are exactly what static rendering rewards. Add a headless CMS if your team needs an editor, while the published pages remain on a CDN.
The Verhuurwinkel case study shows monthly PageSpeed measurements of a real Astro site rather than an isolated benchmark. In Search Console, I have also seen this site’s Astro-related articles appear on the first page for months. That is an observation about this site, not a ranking guarantee. A lightweight frontend supports SEO work by making published content quick to load; it cannot replace useful content or search relevance.
A web app with complex interactions
A customer portal, configurator or dashboard with real-time data needs state management, form logic and server routes that work together. Next.js fits that workload well. You can build it with Astro, but coordinating islands becomes less appealing as application-wide interaction grows. React’s ecosystem has components, libraries and established patterns for this kind of work.
The trade-off is operational: if you use server features, your team must also maintain an application runtime. That is reasonable for an application, but unnecessary baggage for many brochure sites.
E-commerce
It depends on how the store works. If an existing platform handles commerce, a static catalog with an integrated checkout can work well in Astro. A custom store with extensive business logic is closer to an application and more likely to suit Next.js. A classic WooCommerce-style setup is also viable if you take plugin maintenance seriously.
Working with a CMS
Both frameworks work with a headless CMS such as Storyblok. The difference is what you build around the content. For publishing pages that load quickly everywhere, Astro is a natural choice. For content and extensive application logic in one codebase, Next.js often fits better.
If the harder decision is about the CMS rather than the framework, what a headless CMS is explains the architecture. The Storyblok service covers a concrete implementation option.
How I make this decision with a client
I do not decide from a feature checklist. First, I use AI agents running on Hermes to prepare the comparison: analyze existing pages and content, identify the pages and components that need interaction, and compare the current maintenance burden with the candidate stacks. That gives the discussion something more concrete than a developer’s preference.
Then I make the decision with the client. Does the organization suit a modern frontend, or does a familiar dashboard matter more? How much interaction is there really? Who will maintain the site in two years? The agents speed up gathering and comparing information. People make the architecture decision, with the team’s skills, available resources and growth plans in mind.
For help applying that to your project, see Astro website development or web development, or request a conversation.
Five questions to help you choose
- Will the site mainly show content, or do visitors need to sign in, calculate or configure something?
- How many pages need interaction, and how complex is it?
- Who works in the system every day, and how technical is that team?
- Who will maintain it in two years: your team or an external developer?
- How important are load time and Core Web Vitals to your business?
Lots of content and limited interaction point toward Astro. A full application points toward Next.js. A simple site and a preference for dashboard editing may point toward a classic stack. If the answers pull in different directions, discuss the actual requirements before choosing.
Choose for the job your website needs to do
I favor Astro for content-heavy sites where speed matters, and Next.js for applications with substantial interaction and server logic. A classic CMS remains a reasonable choice when simplicity and a familiar dashboard matter most. None wins every project. Pick the tool that fits the work, and be clear about who will maintain it after launch.