Next.js Static Export vs Gatsby for Existing React Sites
Thousands of React content sites — marketing sites, blogs, documentation — were built with Gatsby between 2018 and 2022. Many of them still run. The question their teams face now is not "which is the best static site generator" but something narrower: we have a working Gatsby site and a React team; do we stay, or move, and if we move, to what? For a team that wants to keep React components and React-first pages, the realistic alternative is Next.js with output: 'export'.
This comparison runs the same 800-page React marketing and blog site on Gatsby 5.14 and on Next.js 15 static export with the App Router, measuring build time, output, Core Web Vitals, dependency health and the migration effort. It sits under Next.js Static Export for Content Sites; the case for leaving React-first pages altogether is in Gatsby vs Astro for Content Sites in 2026.
Method
- Site: 800 pages — 620 MDX blog posts, 140 marketing pages built from React components, 40 docs pages — with 1,100 images.
- Gatsby: the site's existing setup —
gatsby-plugin-mdx,gatsby-plugin-image,gatsby-source-filesystem, 19 plugins in total. - Next.js: the same components, MDX through
@next/mdxwith a content loader, images pre-processed at build time with sharp into responsive variants. - Measurement: GitHub Actions 4-core runner, five builds each; Lighthouse 12 mobile on six representative pages, five runs each, both served from Cloudflare.
Build Time
| Measure | Gatsby 5 | Next.js 15 export |
|---|---|---|
| Cold build | 7 min 50 s | 2 min 40 s |
| Warm build (cache restored) | 3 min 05 s | 1 min 55 s |
| Of which image processing | 4 min 10 s (cold) | 1 min 20 s (cold, sharp script) |
| Peak memory | 5.8 GB | 2.9 GB |
Gatsby's cold build was dominated by image processing through gatsby-plugin-sharp, which generated many more variants (including placeholders and several formats) than the Next.js script. Normalising the image work to the same variants narrowed the gap to about 2 minutes, which is Gatsby's GraphQL schema inference and query running.
Page Weight and Core Web Vitals
| Measure (median of 6 pages) | Gatsby 5 | Next.js 15 export |
|---|---|---|
| JavaScript, compressed | 118 KB | 94 KB |
| HTML, compressed | 21 KB | 34 KB |
| LCP, Lighthouse mobile | 1.8 s | 1.6 s |
| Total Blocking Time | 180 ms | 120 ms |
| CLS | 0.01 | 0.02 |
Next.js shipped less JavaScript because blog post bodies and most marketing sections became React Server Components, which send rendered output and no component code. Its HTML was larger because the RSC payload for the page is embedded in the HTML. The differences in LCP and TBT were real but modest: both are React applications that hydrate, and neither comes close to a framework that ships no runtime. If page weight is the main goal, that points away from both.
Dependency Health
This is where the two differ most. Running npm outdated and npm audit on each:
| Measure | Gatsby site | Next.js site |
|---|---|---|
| Direct dependencies | 41 | 17 |
| Total installed packages | 1,890 | 410 |
| Plugins with no release in 18 months | 7 of 19 | 0 |
npm audit high/critical | 9 | 0 |
| Blocked from React 19 by dependencies | Yes | No |
Gatsby's plugin ecosystem is where maintenance risk concentrates: seven plugins the site depended on had not been released in over a year, two pinned old versions of sharp with known vulnerabilities, and the site could not move to React 19 because of peer dependency constraints. Scoring SSG Long-Term Maintenance Risk describes how to score this before it becomes urgent.
Migration Effort
The migration took two developers about three weeks:
| Work | Effort | Notes |
|---|---|---|
| Replace 52 GraphQL queries | 6 days | Mostly data functions, as in Replacing Gatsby GraphQL Queries During a Migration |
| Pages to App Router routes | 3 days | createPages → generateStaticParams |
| Image pipeline | 3 days | sharp prebuild + <picture> component; no placeholders |
gatsby-browser/gatsby-ssr APIs | 1 day | Moved into layout and providers |
| Redirects and URL parity | 2 days | trailingSlash: true matched Gatsby URLs |
| Testing and fixes | 2 days | Output diff, Playwright suite |
Components themselves needed little change: 210 of 240 React components moved unmodified; 30 needed 'use client' because they used state or browser APIs.
What Next.js Export Cannot Do
Static export rules out several Next.js features: next/image optimisation without a custom loader, API routes, middleware, ISR, and dynamic routes not known at build time (Next.js App Router Static Export Limitations lists them). For a Gatsby site, which had none of these either, nothing is lost — but teams sometimes expect them and are disappointed.
Developer Experience Day to Day
Build numbers matter less to the team than the daily loop. The Gatsby dev server took 95 seconds to start on this site and rebuilt GraphQL schema on content changes, occasionally needing gatsby clean to recover from a stale cache. next dev with Turbopack started in 6 seconds and compiled each page on first request, with hot updates under a second for component and MDX edits. Errors were easier to trace, because data loading was ordinary TypeScript functions that appeared in stack traces, rather than GraphQL queries resolved inside Gatsby's node APIs.
The adjustment that took longest was the server and client component split. Developers used to every Gatsby component running in the browser had to learn where 'use client' belongs; a lint rule (react-server-components from the eslint plugin) and a short guide in the repository helped. Within two weeks the team reported preferring the new setup, mainly because dependency upgrades had stopped being an event — Renovate pull requests for Next.js and React merged with green builds, where Gatsby upgrades had needed a person for half a day each.
Verdict
- Stay on Gatsby only if the site barely changes, has no exposure from its outdated dependencies, and a migration is planned within a year.
- Move to Next.js static export if the team writes React and wants pages to stay React: three weeks of work bought a 3× faster cold build, half the memory, a fifth of the dependencies and a path to React 19.
- Move to Astro if page weight matters more than keeping React pages; see the comparison linked above.
Pitfalls
- Comparing builds with different image work. Normalise variants before drawing conclusions.
- Expecting
next/imageto work in export. Plan an image pipeline. - Marking every component
'use client'. It throws away the JavaScript savings; add it only where state or browser APIs are used. - Ignoring URL parity. Match Gatsby's trailing slashes, or redirect.
Conclusion
For an existing React site on Gatsby, Next.js static export keeps the components and the team's habits while replacing an ageing plugin ecosystem. On 800 pages it built three times faster, used half the memory, shipped 20% less JavaScript and needed a fifth of the packages, for about three developer-weeks of migration — with most of the work in replacing GraphQL queries.
FAQ
Is Gatsby still maintained in 2026?
Gatsby receives occasional maintenance releases, but feature development largely stopped after its acquisition, and many plugins have not been updated for recent React and Node versions. A site can keep running on it, but each dependency upgrade gets harder. That maintenance risk, more than performance, is why most teams evaluate leaving.
Why choose Next.js static export over Astro when leaving Gatsby?
Because the team and the components are React. Next.js static export keeps React components, JSX pages and the React ecosystem nearly unchanged, so the migration is mostly replacing GraphQL data access. Astro can render React components too, but its page model, routing and hydration are different and suit teams willing to move away from React-first pages.
Does Next.js static export ship less JavaScript than Gatsby?
In the measurements in this guide, slightly less: 94 KB against 118 KB compressed for a typical article with the App Router and React Server Components, because server components send no component code to the client. Both ship a React runtime for client-side navigation, so neither approaches the near-zero JavaScript of Astro or Eleventy.
What do I lose by leaving Gatsby?
The GraphQL data layer, the plugin ecosystem for sources and images, and features like gatsby-plugin-image's placeholders. Next.js has no static-export image optimisation by default, so images need a build-time pipeline or a custom loader. Incremental builds through Gatsby Cloud are gone too, though Next.js export builds are fast enough on most content sites.
Related
- Parent: Next.js Static Export for Content Sites — Next.js as a static generator.
- Migrating from Gatsby to Next.js Static Export — the migration step by step.
- Gatsby vs Astro for Content Sites in 2026 — the other destination.
- Optimizing Images in Next.js Static Export — replacing gatsby-plugin-image.
- Next.js Static Export vs Astro for Marketing — Next.js against a lighter option.
Filed underComparisonsNext.jsGatsby