Gatsby vs Astro for Content Sites in 2026

In 2019 Gatsby was the obvious choice for a React team building a content site: fast pages, a rich plugin ecosystem, and GraphQL to pull content from anywhere. Seven years later the picture is different. Gatsby's development has largely stopped, its plugin ecosystem is ageing, and the web has moved towards shipping less JavaScript, which is exactly what Gatsby's every-page-is-a-React-app model cannot do. Astro, built around static HTML with optional interactive islands, has become the default many teams reach for instead — including teams with years of React components they would like to keep.

This comparison measures both on the same content site: a 1,200-page company blog and resource library, run on Gatsby 5.14 and then migrated to Astro 5 with React islands, measuring build time, page weight, field Core Web Vitals, dependency health and the cost of the move. It sits in the SSG Framework Selection Matrix; the React-first alternative is compared in Next.js Static Export vs Gatsby for Existing React Sites.

Method

• Content: 1,040 MDX articles, 160 landing and resource pages, 2,300 images, newsletter signup and a filterable resource library as the only interactive features.
• Gatsby 5.14: the production setup, 23 plugins.
• Astro 5.2: same components via @astrojs/react, content collections, astro:assets; the newsletter form and resource filter hydrated with client:visible.
• Lab: GitHub Actions 4-core runner, five builds; Lighthouse 12 mobile on eight pages, five runs each.
• Field: CrUX origin data, 28 days before and 28 days starting four weeks after launch.

Build Time

Both builds spend much of their time on images; Gatsby also spends about two minutes building and querying its GraphQL schema, which Astro does not have.

What Readers Download

The article page is where the architectural difference shows: Gatsby hydrates the whole page as a React app, even though nothing on it is interactive; Astro sends HTML and no JavaScript beyond a tiny analytics snippet. On the one genuinely interactive page, the resource library filter, Astro still ships React for that island — 47 KB — but not for the rest of the page.

Core Web Vitals

The field INP change was the largest: hydrating a full React page on a mid-range phone occupied the main thread for several hundred milliseconds after load, which delayed early taps. With no hydration on article pages, INP fell to 90 ms. The origin moved from "needs improvement" to "good" on all three metrics in CrUX.

Ecosystem Health

The dependency numbers drove the decision more than performance did. The site's security policy required fixing high-severity advisories within 30 days, and three of Gatsby's were in transitive dependencies of unmaintained plugins with no fixed version available.

The Cost of Moving

Three developers took three weeks:

Of 190 React components, 171 moved without change and render to HTML at build time; 19 needed changes, mostly to stop using Gatsby's Link and image components. Migrating from Gatsby to Astro covers the steps, and Replacing Gatsby GraphQL Queries During a Migration the largest part of the work.

When Gatsby Still Makes Sense

Staying put is reasonable for a site that rarely changes, is scheduled for retirement or redesign within a year, and has no unresolved high-severity advisories. Gatsby sites keep building as long as their Node version and dependencies are frozen; the risk is in the day they have to change. For such sites, freezing the build in a container image and recording the dependency audit is a sensible holding position — a plan rather than a migration.

Editorial Workflow After the Move

Writers' daily work changed little: MDX files in the same folders, the same front matter fields apart from two renamed ones, and preview deploys on every pull request. Two things improved noticeably. The dev server started in 4 seconds instead of 70 and reflected MDX edits immediately, where Gatsby had occasionally needed a restart after front matter changes. And content collection schemas caught mistakes that Gatsby had silently accepted — a missing description, a misspelled category — with an error naming the file and field, which the writers initially found strict and later relied on. The first week produced 23 schema errors in existing content, all genuine, which were fixed in one pull request.

Verdict

• For a new content site: Astro (or Eleventy or Hugo, if the team does not need React components). Gatsby is not a reasonable choice for new work in 2026.
• For an existing Gatsby content site with ongoing changes: move to Astro with React islands. On this site it cut cold builds by 85%, article JavaScript by 96%, field LCP from 2.6 to 1.7 seconds and INP from 210 to 90 ms, for three developer-weeks.
• For an existing Gatsby site that is mostly an application: Next.js is the closer fit.

Pitfalls

• Comparing lab numbers only. Field INP showed the largest difference; measure CrUX before and after.
• Hydrating every React component in Astro. Use client directives only where interactivity is needed, or the JavaScript savings disappear.
• Underestimating GraphQL replacement. It is the largest part of the migration.
• Treating "still builds" as "safe". Audit the dependency tree.

Conclusion

Gatsby and Astro both render React components to static HTML, but Gatsby then ships React to every page while Astro ships it only where a component needs it. For a content site that difference decides everything measurable: on 1,200 pages Astro built six times faster, shipped 96% less JavaScript on articles, improved every field Core Web Vital, and replaced an ecosystem with eleven high-severity advisories with one that had none.

FAQ

Should a new content site use Gatsby in 2026?

No. Gatsby still works, but its development has slowed to maintenance releases, many plugins are unmaintained, and it ships a React runtime to every page. For a new content site, Astro, Eleventy or Hugo give better performance with a healthier ecosystem. Gatsby makes sense only for existing sites that are not yet ready to migrate.

How much faster is Astro than Gatsby for a content site?

On the 1,200-page site in this guide, a cold Astro build took 1 minute 25 seconds against 9 minutes 10 seconds for Gatsby, and article pages shipped 6 KB of JavaScript against 141 KB. Field LCP on mobile improved from 2.6 to 1.7 seconds after the move. The size of the gains depends on how much interactivity the pages actually need.

Can Astro use our existing React components from Gatsby?

Yes. Astro's React integration renders React components to HTML at build time, and hydrates them in the browser only when given a client directive. Most presentational components move unchanged. Components that relied on Gatsby APIs such as useStaticQuery or gatsby-plugin-image need their data or images passed in differently.

What is the biggest cost of moving from Gatsby to Astro?

Replacing the GraphQL data layer and Gatsby-specific plugins. Pages built around page queries become content collection queries, and image handling moves to Astro's image service. In the migration measured here this was about 60 percent of the three-week effort; the components themselves were the easy part.

Related

• Parent: SSG Framework Selection Matrix — comparing generators against team constraints.
• Migrating from Gatsby to Astro — the migration step by step.
• Next.js Static Export vs Gatsby for Existing React Sites — the React-first alternative.
• Astro Islands vs Full Hydration Performance — why islands change INP.
• Scoring SSG Long-Term Maintenance Risk — measuring ecosystem health before choosing.