You set out to publish a simple documentation site—one search box, a few Markdown pages—yet Gatsby hands you a GraphQL schema, dozens of plugins, and a React bundle that tops 300 KB after hydration. Astro tackles the same job with mostly static [HTML](https://strapi.io/blog/html-tips), shipping JavaScript only to the parts that need it. This fundamental difference—React-everywhere versus use-what-you-need—shapes your site's performance, and your team's learning curve. You'll see side-by-side bundle sizes, build times, Lighthouse scores, and real code diffs to help you decide when Gatsby's opinionated power makes sense and when Astro's flexibility wins. **In brief:** * Astro ships 40x less JavaScript by hydrating only interactive components (5 KB) versus Gatsby's full React runtime (200+ KB) * Build times scale differently with Astro building 40 pages in 10 seconds versus Gatsby's 2-3 minutes * Framework flexibility varies as Astro supports mixing React, Vue, and Svelte while Gatsby requires React exclusively * Developer experience diverges immediately from Astro's instant HTML coding to Gatsby's plugin and GraphQL setup ## **Astro vs Gatsby: A Quick Comparison** Before diving deep, here's what separates Astro and Gatsby at a glance: | Aspect | Astro | Gatsby | | ----- | ----- | ----- | | **Architecture** | Islands (selective hydration) | SPA (full hydration) | | **JavaScript Shipped** | \~5 KB (only interactive parts) | 200+ KB minimum (React everywhere) | | **Build Time (40 pages)** | \< 10 seconds | 2-3 minutes | | **Framework Lock-in** | Mix React, Vue, Svelte, or none | React only | | **Data Layer** | Plain `fetch()` and imports | GraphQL required | | **Rendering Options** | SSG/SSR per component | SSG/SSR for entire app | | **Developer Experience** | Write HTML, add JS where needed | Configure plugins, write queries | | **Learning Curve** | HTML \+ CSS \+ any JS | React \+ GraphQL \+ Gatsby APIs | | **Best For** | Content sites with selective interactivity | React apps with complex data needs | ## **Core Architecture Comparison** You'll feel the architectural differences between [Astro](https://strapi.io/integrations/astro) and [Gatsby](https://strapi.io/integrations/gatsby-cms) the moment you open DevTools. Astro keeps the network tab nearly empty, while Gatsby ships a full React bundle for every page. Understanding why will help you pick the [right tool for the job](https://strapi.io/blog/nextjs-vs-astro-vs-remix-choosing-the-right-frontend-framework). ### **Astro's Island Architecture** Astro's approach centers on what they call "islands"—interactive components that hydrate independently while the rest of your page remains static HTML: ```javascript --- // src/pages/index.astro import Counter from '../components/Counter.jsx'; ---

Welcome to Islands

This page is plain HTML until the button below loads.

``` ```javascript // src/components/Counter.jsx import { useState } from 'react'; export default function Counter() { const [count, setCount] = useState(0); return ; } ``` Astro takes a surgical approach to JavaScript delivery. It pre-renders pages as static HTML, then selectively hydrates only interactive components—like a Counter button at \~5 kB versus 200+ kB for a full React runtime. The difference? Astro sends JavaScript only where interactivity lives, not everywhere by default. No global app mounting, no unnecessary client-side routing. Developers migrating from Gatsby notice the impact immediately: bundle sizes drop by an order of magnitude and builds finish in seconds instead of minutes. Since hydration is opt-in, you can mix frameworks freely—rendering a Svelte carousel next to a [React form](https://strapi.io/integrations/react-cms) without paying the runtime cost everywhere else. This HTML-first, JavaScript-as-needed architecture makes content-heavy sites feel instantaneous. ### **Gatsby's React Foundation** Gatsby takes a different approach: everything is a React component, and every page hydrates into a single-page application. ```javascript // src/pages/about.js import React from 'react'; export default function About() { return (

About

This page loads as static HTML, then React takes over.

); } ``` During the build, Gatsby pre-renders HTML, but the client still downloads the full React bundle so the app can rehydrate and handle navigation. The framework's GraphQL layer stitches together content from Markdown, CMSs, and APIs, giving you type-safe queries at build time. When your data model is complex—think products with reviews, authors, and categories—that extra abstraction pays off by normalizing everything into a single schema. The flip side is added complexity: you maintain `gatsby-config.js`, install source plugins, and write GraphQL queries even for simple pages. All this lives inside React's mental model, so teams already fluent in React feel at home, while others face a steeper ramp. ### **Rendering Strategies Compared** Both frameworks offer multiple rendering options, though they implement them differently: | Strategy | Astro | Gatsby | Typical Use-Case | Complexity | | ----- | ----- | ----- | ----- | ----- | | SSG | ✅ | ✅ | Blog post | Low | | SSR | ✅ | ✅ | User dashboard | Medium | | ISR/DSG | ✅ *(*`prerender`*)* | ✅ *(DSG)* | Frequently updated docs | Medium | | Edge Rendering | ✅ | ❌ | Personalized homepage | High |
Astro lets you decide per page and even per component, thanks to its island model, so you can mix [static marketing pages](https://strapi.io/blog/static-website-vs-dynamic-website) with SSR account areas without changing projects. Gatsby offers the same menu (SSG, SSR, Deferred Static Generation), but every option still hydrates the full React bundle, which influences runtime performance and build speed. ## **Developer Experience** Great developer tools get out of your way; you should be writing components, not fighting configuration. Astro and Gatsby reveal their philosophies from the first command: one drops you straight into code, the other into decisions. ### **Setup and Learning Curve** Spinning up a fresh Astro project feels like scaffolding plain HTML: ```shell # 00:00 create npm init astro my-site -- --template blog # 00:15 install deps cd my-site && npm install # 00:40 dev server npm run dev # 01:10 deploy (Vercel) git push && vercel --prod ``` Prerequisites: HTML, CSS, and whatever JavaScript framework you prefer. A single ```astro.config.mjs``` handles paths, markdown settings, and integrations. Data fetching is direct—import markdown via ```import.meta.glob()``` or call [REST API](https://docs.strapi.io/cms/api/rest)s with ```await fetch```. No GraphQL required. Gatsby starts friendly but branches into its opinionated ecosystem: ```shell # 00:00 create npx gatsby new my-site https://github.com/gatsbyjs/gatsby-starter-blog # 00:45 install plugins cd my-site && npm install gatsby-plugin-image gatsby-source-filesystem # 02:30 dev server gatsby develop # 05:00 first build gatsby build ``` Beyond React and Node.js, you'll need to grok Gatsby's GraphQL data layer—a powerful abstraction that unifies all data sources but demands its own learning curve. Every data decision flows through ```gatsby-config.js```, plugin configurations, and GraphQL queries. The payoff is sophisticated data aggregation; the price is cognitive overhead before writing your first component. ### **Project Structure** Astro keeps the file tree lean and familiar: ``` my-astro-site/ ├─ src/ │ ├─ pages/ │ │ └─ index.astro │ └─ components/ │ └─ Nav.astro ├─ public/ ├─ astro.config.mjs └─ package.json ``` File-based routing: drop an ```.astro```, ```.md```, or ```.svelte``` file in ```src/pages/``` and it becomes a route. No wiring required. Gatsby inserts more moving parts: ``` my-gatsby-site/ ├─ src/ │ ├─ pages/ │ │ └─ index.js │ └─ templates/ │ └─ blog-post.js ├─ static/ ├─ gatsby-config.js ├─ gatsby-node.js └─ package.json ``` Three configuration files orchestrate the build: ```gatsby-config.js``` manages plugins, ```gatsby-node.js``` programmatically creates pages, and `gatsby-browser.js` (often added later) handles client-side concerns. This machinery enables powerful data transformations and dynamic page generation, but even a blog needs to understand the whole system. The difference is philosophical: Astro starts minimal and lets you add complexity. Gatsby starts with a framework and asks you to work within it. ### **Framework Flexibility** Astro's island architecture treats [UI libraries](https://strapi.io/blog/top-5-best-ui-libraries-to-use-in-your-next-project) like interchangeable components: ```js --- // src/pages/index.astro import Counter from '../components/Counter.jsx' // React import Sun from '../components/Sun.svelte' // Svelte ---

Hello Islands

``` React and Svelte components sharing the same page, each shipping only their required runtime. Your team can use Vue for marketing widgets and React for dashboards in the same codebase—no rewrites, no iframes, no compromises. Gatsby commits you to React entirely. This focus creates a cohesive ecosystem—every plugin, pattern, and tutorial speaks the same language. But adding Svelte means starting a new project or awkward workarounds. The practical difference: Astro gives you tool-per-component autonomy with light bundles; Gatsby provides a mature React-centric plugin ecosystem with consistent patterns but heavier client JavaScript. ## **Data Layer Deep Dive** The most fundamental difference between these frameworks lies in how they handle content and API data. This choice affects everything from your daily development workflow to long-term site performance. ### **Gatsby's GraphQL Approach** Spin up a new Gatsby project and within minutes you're writing GraphQL. A typical first query looks like this: ```js query BlogPost { markdownRemark(frontmatter: { slug: { eq: "hello-world" } }) { frontmatter { title } html } } ``` That single query delivers typed data in one call—no REST juggling required. The complexity surfaces when you start stitching multiple sources together. Two days in, you're adding filters, sorting, and relationships: ```js query PostsAndProducts { allMarkdownRemark(sort: {frontmatter: {date: DESC}}, limit: 10) { nodes { frontmatter { title date } excerpt } } allShopifyProduct(filter: {availableForSale: {eq: true}}) { nodes { title priceRange { minVariantPrice { amount } } } } } ``` Now you're unifying Markdown, Shopify, and headless CMS data through one query layer—powerful, but demanding. What starts as "learning GraphQL basics" evolves into mastering Gatsby's node APIs, schema customization, and resolver logic. The payoff: automatic image optimization, cross-source relationships, and consistent data transforms. The price: every content change triggers GraphQL re-execution, pushing build times from seconds to minutes. Large sites need incremental builds just to stay responsive. Developers describe a learning curve that shapeshifts, where an afternoon of curiosity becomes weeks of schema debugging as the project scales. GraphQL delivers on its promise of unified data, but in Gatsby's hands, it's both the framework's greatest strength and its most divisive requirement. ### **Astro's Flexible Data Fetching** Astro uses the JavaScript you already know. Three approaches cover most use cases: ```javascript --- // 1. Local glob import const posts = await import.meta.glob('./posts/*.md', { eager: true }); --- ``` ```javascript --- // 2. Direct API call const res = await fetch('https://api.example.com/articles'); const articles = await res.json(); --- ``` ```javascript --- // 3. ESM import of static data import products from '../data/products.json'; --- ``` No GraphQL layer, no hidden nodes, just data where you need it. Because Astro renders at build time, these calls run once and vanish from the client bundle. Developers migrating from Gatsby report builds dropping "from several minutes to under a minute" on similarly sized sites, thanks to skipping query compilation and heavy plugin chains. Mixing sources is straightforward: fetch a headless CMS entry, merge it with local Markdown, render, and you're done. The trade-off appears when relationships get complex. Without a unified schema, you hand-roll joins and transformations, which becomes brittle on very large, editorially driven projects. For most content-first sites, you gain faster builds, smaller bundles, and framework flexibility—benefits that align with Astro's "use only what you need" philosophy. ## **Ecosystem and Extensibility** The plugin ecosystem tells a story about maturity versus simplicity. Gatsby offers several thousand plugins covering everything from CMS sources to image optimization, while Astro's collection is smaller but growing rapidly. Consider image handling—a common pain point. Gatsby's mature "Gatsby Plugin Image" handles responsive images, AVIF/WebP conversion, and lazy-loading out of the box. Astro uses ```@astrojs/image```, a solid but evolving alternative. Configuration differs significantly: ```javascript // astro.config.mjs – 3 lines import { defineConfig } from 'astro/config'; import image from '@astrojs/image'; export default defineConfig({ integrations: [image()] }); ``` ```javascript // gatsby-config.js – 7 lines module.exports = { plugins: [ { resolve: 'gatsby-plugin-image', options: {}, }, ], }; ``` Astro requires less configuration boilerplate. Gatsby's plugin richness accelerates feature development; source, transform, and SEO plugins connect [headless CMSs](https://strapi.io/blog/headless-cms-vs-headless-word-press) quickly, but it requires vetting each plugin's maintenance status, version compatibility, and GraphQL integration. Astro often requires writing small fetch functions directly, trading abstractions for predictability. From a community perspective, Gatsby's established ecosystem shows in numbers: more [GitHub stars](https://github.com/gatsbyjs/gatsby), active Discord channels, and extensive Stack Overflow archives. You rarely get stuck without examples or workarounds. Astro's community is newer but highly responsive—Discord threads often get replies within minutes, and documentation stays current with migration guides addressing real implementation challenges. Gatsby material is plentiful but sometimes outdated; Astro resources are fewer but reflect the latest API. Choose Gatsby for extensive plugin coverage and battle-tested solutions. Choose Astro for rapid community feedback, modern documentation, and minimal configuration overhead. ## **Deployment and Infrastructure** How these frameworks handle production deployment reveals another key difference in philosophy and practical outcomes. ### **Platform Support** Astro's static output simplifies deployment compared to Gatsby's React foundation. The difference shows in deployment complexity: | Hosting platform | Astro | Gatsby | Deployment complexity\* | | ----- | ----- | ----- | ----- | | Vercel | ✔ static or SSR | ✔ static, Functions, SSR | low / medium | | Netlify | ✔ static & Edge Functions | ✔ static, Functions | low / medium | | Cloudflare Pages | ✔ static, Workers SSR | ✔ static, Workers SSR | low / medium-high | | Gatsby Cloud | — | ✔ static, incremental builds | — / low |

Real migrations show the difference: [a 40-page site moved from Gatsby to Astro](https://www.helmerdavila.com/blog/en/why-and-how-i-moved-my-blog-away-from-gatsby-and-react-to-astro-js-and-preact) dropped build time from 2 minutes 45 seconds to under 50 seconds. Deployment became a single `npm run build` and GitHub push—no plugins needed for images or GraphQL sourcing. Gatsby remains smooth on the same hosts, but typically requires plugin configuration and incremental builds to manage CI costs. ### **Edge Deployment** Astro's minimal JavaScript approach creates advantages at the edge. Since Astro ships only JavaScript for interactive "islands," HTML caches and serves from edge locations with virtually zero overhead. You can deploy Server-Side Rendering handlers as Cloudflare Workers without bundle bloat. Gatsby supports Workers, but every page hydrates into a full React app. That extra payload impacts the sub-100ms latency budgets required at the edge. For content-heavy sites with minimal interactivity, the difference is measurable: smaller bundles mean faster cold starts, lower egress costs, and reduced throttling under load. Gatsby's edge story works when you need React logic or per-request GraphQL queries, but you'll trade speed for that flexibility. **Note:** In case you are looking for another cloud option, consider [Strapi Cloud](https://strapi.io/cloud). Strapi Cloud is a good option for hosting JavaScript frameworks because it provides a managed backend with APIs (REST/GraphQL), a built-in database, and global CDN delivery, making it easy for frontends like React, Astro, or Gatsby to fetch content quickly. Strapi Cloud removes the need to manage servers or databases, while offering scalability, security, and Git-based workflows. This lets developers focus on building the frontend while Strapi handles content infrastructure and performance. ## **Use Case Analysis** Most framework decisions come down to three factors: how much interactivity you need, team composition, and performance requirements. You can usually determine the right fit within minutes by answering these core questions. ### **When to Choose Astro** Astro works best when content takes center stage and interactivity is selective rather than pervasive. This includes content-driven sites like marketing pages, documentation, blogs, and portfolios. The ideal scenarios include: * Most content is static with minimal interactive elements * JavaScript payload must stay small for mobile users on slow networks * Your team uses mixed frameworks (React, Vue, Svelte) or prefers plain HTML * Build speed matters more than rich client-side app functionality * Direct API calls work better than a unified GraphQL layer ### **When to Choose Gatsby** Gatsby is ideal for React-powered applications with complex data orchestration—e-commerce platforms, SaaS marketing sites, enterprise portals, content hubs—where multiple data sources need unification and users expect rich, app-like interactions throughout their journey. The sweet spot includes: * Your React-focused stack aligns with existing component libraries and team skills * Complex data relationships from multiple CMSs and APIs benefit from unified GraphQL * You need mature plugin ecosystem features like advanced image optimization or CMS previews * Incremental builds on Gatsby Cloud can offset longer full builds * Heavy client-side interactivity and SPA-style navigation are essential ## **The Verdict: Architecture Shapes Everything** The choice between Astro and Gatsby reflects two opposing philosophies about the modern web. Astro believes most websites are documents with sprinkles of interactivity. Its island architecture ships HTML by default, JavaScript by exception. You write less configuration, build faster, and ship smaller bundles because complexity is opt-in, not opt-out. Gatsby sees the web as interconnected applications that serve content. React and GraphQL aren't overhead; they are the foundation for orchestrating complex data relationships and rich interactions. The framework's complexity enables sophisticated content applications that would be painful to build from scratch. * Choose Astro when performance budgets are tight and users primarily read content. * Choose Gatsby when React is your standard and your data relationships justify the abstraction.

Gatsby

The Developer's Guide to Generating Static Sites with Gatsby

Join our Newsletter