Three frameworks, one content-heavy brief
Clients keep asking the same question: if you were starting a content-heavy marketing site today, which framework would you reach for? To answer it, we rebuilt the same fictional brief three times, using Astro, Next.js and Gatsby. Same pages, same CMS, same image pipeline. What came out the other side tells a story about where each framework sits in 2026.
The brief
A mid-sized publisher with roughly 1,500 articles pulled from a headless CMS, a dozen author pages, tag and category archives, a newsletter signup and a single interactive pricing calculator. Content updates daily but is not personalised. Solid SEO requirements, CWV targets in the green, and editors who expect previews.
That profile is deliberate. It is the sweet spot where all three frameworks claim a win, and where the differences show up in practice.
Rendering models, honestly
Each framework approaches the same problem from a different angle.
- Astro runs an islands architecture. The whole page ships as static HTML with zero JavaScript by default. Interactive components are opted-in and hydrated individually.
- Next.js runs React Server Components via the App Router. Components render on the server, only the interactive ones hydrate on the client, and ISR can regenerate pages on a cadence.
- Gatsby still leans on build-time static generation with a unified GraphQL data layer. Client-side React takes over after hydration.
The practical upshot: Astro sends the least JavaScript, Next.js sends the most flexibility, and Gatsby sends a familiar model that has not moved much since 2022.
Build times on 1,500 pages
Build time matters when editors want to see a typo fix on production in under five minutes. Our experience on this build mirrored what we see across client projects.
- Gatsby took the longest by a comfortable margin. Its image processing is thorough but slow, and incremental builds help less than you would hope once the cache is cold.
- Next.js was quicker, and ISR meant we did not need to rebuild 1,500 pages on every content change. Most edits regenerated a handful of routes.
- Astro was the fastest end-to-end. Fewer moving parts, no React runtime to bundle for static content, and content collections that stream through without a GraphQL layer in the middle.
For a content site with frequent editorial updates, Astro and Next.js (with ISR) pull ahead. Gatsby's build times are its biggest weakness in 2026.
Runtime performance
All three can hit green Core Web Vitals on a marketing page if you build them carefully. The difference is how much effort it takes.
Astro sets you up to win by default. You have to actively add JavaScript to slow it down. An Astro article page ships kilobytes of JS, not hundreds of kilobytes.
Next.js with the App Router is close behind when you lean on Server Components and keep 'use client' boundaries tight. The ceiling is high, but the floor depends on discipline. It is easy to accidentally ship a large client bundle.
Gatsby's runtime is fine, but it forces React onto every page whether you need it or not. On a pure content page, that is dead weight.
Developer experience
Astro
Astro files feel like HTML with superpowers. You can drop in React, Vue, Svelte or Solid components where you need interactivity, and static markup everywhere else.
---
import Article from "../layouts/Article.astro";
import Calculator from "../components/Calculator.jsx";
const { entry } = Astro.props;
---
<Article title={entry.title}>
<Fragment set:html={entry.body} />
<Calculator client:visible />
</Article>
That client:visible directive hydrates the calculator only when it scrolls into view. That is the entire mental model.
Next.js
Next.js is the most capable of the three, and the one where you need to think hardest. Server Components, Client Components, Route Handlers, middleware, caching layers, fetch semantics. It is capable, but onboarding a new developer takes longer than it used to.
Gatsby
Gatsby's developer experience has barely changed in years. The GraphQL data layer is elegant for multi-source projects, but plugin maintenance has slowed visibly and several high-profile plugins are stale or unmaintained.
Ecosystem in 2026
- Next.js has the deepest component ecosystem, the most tutorials, the most hires available across Australia, and the closest alignment with modern React.
- Astro has grown fast. It now has solid integrations for every major CMS, good image tooling, View Transitions, and an active community.
- Gatsby is the concerning one. Vercel acquired Netlify's Gatsby assets, the release cadence has slowed, and we recommend it for new builds less often than we did two years ago.
We still maintain and extend plenty of existing Gatsby sites. What we are not doing is reaching for it first on greenfield work.
When each one wins
Astro wins on content-heavy marketing sites, blogs, documentation and publishers where interactivity is the exception rather than the rule. If your site is mostly reading, Astro should be your default.
Next.js wins on anything dynamic. Authenticated dashboards, eCommerce, personalisation, streaming UIs, places where you need both a frontend and an API in the same project. When the requirements get complicated, Next.js is the right call.
Gatsby wins in a narrow band: existing Gatsby sites where the team is productive, or builds that lean heavily on its mature image pipeline and GraphQL data layer. Outside that, the competition has caught up and moved past it.
Migration cost, honestly
One question we get almost every time a framework comparison comes up is "how hard is it to move?"
Moving from Gatsby to Astro is the easiest of the three directions. Both treat pages as files, both have strong static-first defaults, and most Gatsby components can be brought across with light modification. The harder work is translating GraphQL queries into content collections and reworking the image pipeline.
Moving between Gatsby and Next.js is a bigger lift, mostly because Next.js expects a different mental model. Routing, data fetching and image handling all change.
Moving from Next.js to Astro rarely makes sense unless the site has become static in practice. If you need Server Components, streaming UIs and API routes, Astro is not trying to replace that.
Our 2026 default
For new content-heavy work, we now start with Astro unless the brief pushes us toward Next.js. For anything with authentication, real-time data, or a serious amount of application logic, we stay with Next.js. If you are weighing up a rebuild or starting something fresh, we would love to talk through which direction fits your project.
