Gatsby was the right answer for most of the 2018–2022 era of static site development. It introduced GraphQL-based content sourcing, a rich plugin ecosystem, and a modern JavaScript-first approach to marketing sites. None of that was nothing. But the architecture that made Gatsby innovative in 2018 became its liability by 2022 — and Astro’s growth since then reflects that directly.
Gatsby at Its Peak
To understand why Gatsby lost ground, understand what it was solving.
In 2018, most marketing sites were built on WordPress or static site generators like Jekyll and Hugo that were fast but required Ruby or Go knowledge and produced minimal interactivity. Gatsby offered React components, JavaScript tooling developers already knew, and a plugin ecosystem that connected to every data source. It was genuinely better than the alternatives at the time.
Gatsby’s GraphQL data layer was ambitious: query your content from any source — WordPress, Contentful, Markdown files, APIs — through a unified GraphQL schema at build time. For developers managing multi-source content, this was a real workflow improvement.
At its peak, Gatsby powered some of the fastest sites on the internet. Lighthouse scores of 90–95 were common on well-built Gatsby sites. The framework had 50,000+ GitHub stars, a thriving plugin directory, and commercial backing from Gatsby Inc., which raised $15 million in 2019 and $28 million in 2021.
Acknowledging this matters. Gatsby was not hype. It was a real technology that solved real problems and built a real ecosystem.
What Went Wrong With Gatsby
JavaScript Overhead That Never Left
Gatsby’s fatal architectural decision was shipping React to every page.
Gatsby is a React framework. Every Gatsby page is a React component. When a Gatsby site builds, it produces HTML for each page (for SEO and initial load), then rehydrates that HTML into a full React application on the client. This is called “hydration,” and it means every Gatsby page — even a purely static blog post — ships React runtime, routing logic, and framework overhead to the browser.
A typical Gatsby build ships 150–300KB of JavaScript before your content is interactive. On a static blog post with zero interactive elements, that JavaScript does nothing useful. The visitor’s browser downloads it, parses it, and executes it. On a mid-range Android phone, that process takes 1–3 seconds.
This was an acceptable tradeoff in 2018 when the alternative was unmaintainable jQuery spaghetti. By 2021, it was an architecture problem. Core Web Vitals were introduced as a Google ranking signal. Total Blocking Time — directly caused by JavaScript execution — started affecting rankings. Gatsby’s hydration model was producing TBT numbers in the 200–600ms range on sites with modest content.
Attempts to fix this with Gatsby’s “partial hydration” and “script” component API (Gatsby v4, 2021) were incremental improvements on a structural problem. The React runtime was still shipping.
Build Times That Made Developers Dread Deployments
Gatsby’s build system became notorious for slow build times at scale.
A 500-page Gatsby site in 2020 could take 8–15 minutes to build. A 2,000-page site could take 45 minutes to an hour. The GraphQL data layer, while powerful, added significant overhead to the build pipeline. Image processing (Gatsby Image) was thorough but computationally expensive.
Gatsby introduced incremental builds and cloud-based build caching in 2020–2021. These helped — builds on Gatsby Cloud (their proprietary hosting) were meaningfully faster. But “you need our specific platform for acceptable build performance” was not the right answer. It also contributed to what happened next.
The Netlify Acquisition and Ecosystem Decline
In 2023, Netlify acquired Gatsby Inc. The stated goal was to continue development. In practice, core Gatsby team members left. The release cadence slowed. Community activity dropped. The plugin ecosystem — which had been Gatsby’s strongest selling point — began to stagnate.
Gatsby’s npm downloads peaked in late 2022 and have declined since. GitHub activity shows significantly fewer commits and maintained issues compared to Astro, which is on an upward trajectory. Netlify has explicitly repositioned Gatsby as a “maintenance mode” technology rather than an active-development framework.
This is a business risk. Choosing a framework depends partly on whether it will be maintained and improved. Gatsby’s acquisition and the subsequent team exodus changed that calculus.
How Astro Compares on the Same Metrics
JavaScript Output
Astro ships zero JavaScript by default. Not “less JavaScript than Gatsby” — zero. A static Astro page with no interactive components produces HTML and CSS. No React. No framework runtime. No hydration.
When a page needs interactivity, Astro’s Islands architecture loads JavaScript only for that component, not for the entire page. A contact form on an Astro page loads form JavaScript. The headline, navigation, body copy, and footer load none.
The measurable result: Astro sites average near-zero Total Blocking Time. Gatsby sites average 200–400ms TBT on content-focused pages. On mobile Lighthouse, that difference is the gap between a 95 score and a 72 score on otherwise identical content.
The JavaScript payload comparison tells the same story. A blog post on a well-optimized Gatsby site ships 150–200KB of JavaScript. The same blog post built in Astro ships under 5KB — sometimes zero. That’s a 97%+ reduction for static content.
Build Times
Astro builds are fast. A 500-page Astro site builds in 45–90 seconds on modern hardware. A 2,000-page site builds in 3–5 minutes. No proprietary build platform required. Standard CI/CD on GitHub Actions or the free build tiers on Vercel, Netlify, or Cloudflare Pages handles it.
The Astro compiler is written in Rust, which contributes to its speed. Astro’s build pipeline doesn’t run a GraphQL layer unless you add one — and most projects don’t. Build time predictability is consistent.
Ecosystem Health
Astro’s npm downloads have grown continuously since its 1.0 release in 2022. The framework is maintained by The Astro Technology Company, which raised $7 million in funding in 2023 with a clear commercial mandate around the core open-source project.
Astro has 45,000+ GitHub stars (comparable to Gatsby’s peak) with active maintenance, regular minor releases, and a growing integration directory. The integrations cover the major headless CMS options (Sanity, Contentful, Storyblok, Prismic, DatoCMS), e-commerce platforms, and component frameworks.
The trajectory matters for a decision you’re making now. Astro is on an upward development curve. Gatsby is in maintenance mode.
When Gatsby Still Makes Sense
Be honest about this: Gatsby still makes sense in specific situations.
If you have an existing Gatsby site with a large, functional plugin set and a development team that knows the codebase, migrating to Astro is a cost, not a free performance upgrade. The migration cost has to be weighed against the performance and maintenance gains. For a site that isn’t performance-constrained and has no upcoming rebuild, staying on Gatsby is reasonable.
If your developer team is deeply invested in the Gatsby/React ecosystem and migration to Astro would require significant retraining, that’s a real cost. Gatsby React components and Astro components are not a direct swap.
Gatsby’s GraphQL data layer — while slower than Astro’s build approach for small to medium sites — handles genuinely complex multi-source content architectures with a level of query expressiveness that Astro’s content collections don’t fully replicate. For sites with 10+ content sources, complex content relationships, and developers who want a unified query interface, Gatsby’s data model still has architecture merits.
The Migration Question
If you’re on Gatsby and considering Astro, the question is whether the performance gap is costing you money.
If you’re running Google Ads to a Gatsby landing page with a 65 Lighthouse score and a 400ms TBT, you’re paying higher CPCs than an equivalent Astro page would require. The math: a Quality Score increase from 6 to 9 on a $5,000/month ad account can reduce CPCs by 30–40%. That’s $1,500–2,000/month in recovered budget. A new build pays for itself.
If your site isn’t on Google Ads and isn’t performance-constrained (already scores 85+ on mobile Lighthouse), migration is a lower priority. The ecosystem risk from Gatsby’s maintenance-mode status is real but not immediate.
For context on what Astro performance actually looks like in production, see Astro performance benchmarks and SEO. For how the framework architecture differs from other JavaScript options, Astro vs Next.js for marketing sites covers the comparison in detail.
The Honest Summary
Gatsby pioneered the modern static site approach and deserves credit for it. Its plugin ecosystem, GraphQL data layer, and React foundation moved the industry forward.
Astro learned from Gatsby’s architecture and fixed the core mistake: shipping React to pages that don’t need it. Zero-JavaScript defaults, Islands architecture, fast builds, and a healthy maintained ecosystem make Astro the better choice for new marketing site builds in 2026.
The switchover from Gatsby to Astro as the default SSG for marketing sites happened in 2022–2023 and wasn’t a close call. Download trends, GitHub activity, developer surveys (State of JS 2023, 2024), and agency adoption all point the same direction.
If you’re choosing a framework for a new build today, there’s no scenario where you’d choose Gatsby over Astro for a content or marketing site. If you’re maintaining an existing Gatsby site, the migration decision depends on performance gaps, ad spend, and development team context.
If you’re comparing more broadly — including the WordPress decision — see when to choose Astro over WordPress for a framework-neutral decision guide.
FAQ
Is Gatsby dead? “Dead” is imprecise. Gatsby is in active maintenance under Netlify — security patches and compatibility updates are being released. Active feature development has slowed significantly since the acquisition and team exodus. For new projects, it’s not a recommended choice. For existing projects, it’s not an emergency, but migration should be on the roadmap.
Can I use my existing Gatsby components in Astro? Astro supports React components as Islands. If your Gatsby site uses React components for interactive elements, those components can often be used in Astro with minimal modification. The layout components, data fetching patterns, and GraphQL queries will need to be rewritten — Astro uses a different content model. A typical Gatsby-to-Astro migration is a partial rebuild, not a line-by-line conversion.
Does Astro have Gatsby’s GraphQL data layer? No. Astro doesn’t use GraphQL for content by default. It uses “content collections” — TypeScript-typed Markdown or MDX files — and direct API calls to headless CMS endpoints. For multi-source content, you query each source directly in your Astro components or generate content at build time with utility scripts. Some developers add a GraphQL layer on top of Astro, but it’s an addition, not the default. For most marketing sites, the simpler model is sufficient.
How long does a Gatsby-to-Astro migration take? Depends heavily on site complexity. A 10-page marketing site: 1–3 days of development. A 50-page site with CMS integration: 1–2 weeks. A complex site with many plugin dependencies and custom functionality: 3–6 weeks. The migration is not trivial, but the performance gains on a high-traffic site justify it. Our custom WordPress development and Astro builds come with fixed scopes — contact us via fixed-price packages for an estimate on migration specifically.
Is Astro better than Gatsby for SEO? For technical SEO, yes — materially. The JavaScript reduction and corresponding TBT improvement directly affect Core Web Vitals scores. The static HTML output is more reliably indexed than JavaScript-rendered content. Build times are better, which means more frequent deploys and fresher content. Neither Astro nor Gatsby provides SEO metadata management out of the box — that’s custom implementation on both platforms.
What about Next.js instead of Gatsby or Astro? Next.js is a strong framework for applications — sites with significant dynamic functionality, user authentication, complex server-side logic. For primarily static marketing sites, Next.js ships more JavaScript overhead than necessary (similar to Gatsby’s problem, though Next.js is actively maintained and improving). Astro vs Next.js for marketing sites covers that comparison directly. For static content marketing sites, Astro is the more appropriate tool than Next.js.