Astro vs. Next.js: which framework fits your website?

What are Astro and Next.js designed for?

Both are frameworks for building websites, but they have different priorities.

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:

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. Hydration is the step in which the browser makes a server-rendered component interactive after the page loads.

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 measurements of real websites show: 71.1% vs. 35.7%

As of the September 2026 dataset, the HTTP Archive Tech Report shows 71.08% of 47,277 tested mobile Astro origins (33,605 origins) passing Core Web Vitals, compared with 35.66% for Next.js. An origin groups pages by protocol, host, and port; it is not an individual page. The difference is about 35.42 percentage points. September 2026 was the newest month when I collected these figures on November 4, 2026. HTTP Archive publishes the report monthly, so later months can show slightly different percentages.

The report lists more mobile Astro origins for First Contentful Paint (49,450). That larger group is not the denominator for the Core Web Vitals result.

In the same comparison, WordPress reached 48%, Gatsby 44% and Nuxt.js 29%. The whole percentages in the chart below are rounded the way the HTTP Archive site rounds them, including Astro at 71% and Next.js at 36%.

These are field measurements from the Chrome UX Report (CrUX), which covers eligible participating Chrome users, not all visitors or browsers. This is 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 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. In September 2026, the twelve other case sites had a median of 100/100 for their best mobile PageSpeed score that month; the lowest of those twelve scores was 94. The fastest Lab LCP among those best measurements was 939 milliseconds.

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 add content to 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 complex interaction and server logic your project needs, the further it moves from Astro’s static comfort zone.

Not sure which stack fits your plans? I can help weigh the trade-offs rather than start with a framework preference.

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

For pages that must load quickly everywhere, Astro is the natural choice. For content and extensive application logic in one codebase, Next.js often fits better. Both frameworks work with a headless CMS such as Storyblok; the difference is what you build around the content.

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.

Can you use both, or move from Next.js to Astro?

Yes. Astro has official integrations for React, Preact and Solid, so many existing JSX components can keep working inside an Astro page as islands. The page around them becomes static HTML.

A common split is a marketing site on Astro next to an application on Next.js, for example the website on the main domain and the app on its own subdomain. Each part then uses the framework that suits it, and the marketing pages do not carry the app’s JavaScript.

Moving an existing Next.js site to Astro means rebuilding the pages, layouts and data fetching. It is not a setting you switch. Astro’s migration guide from Next.js lists what changes. Start with the pages that get the most search traffic, and measure them before and after the move.

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. They analyze existing pages and content, find the pages and components that need interaction, and compare today’s maintenance work with each candidate stack. That gives the discussion something more concrete than a developer’s preference.

Then I decide together with the client. Does a modern frontend suit the organization, 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 get in touch.

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 based on what 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.