Gatsby logo

Gatsby

A data-layer focused React framework designed for building performant, content-driven websites.

npm install gatsby
56.0K331.4K/weekv5.15.06.67 MBMIT347 issues
Last updated: 2025-08-28
Star history chart for gatsbyjs/gatsby

TL;DR

A static site generator and React framework that unifies data from multiple sources into a single GraphQL API.

Best suited for content-heavy sites like blogs, e-commerce storefronts, and marketing pages where image optimization and SEO are critical.

Why Gatsby?

Gatsby distinguishes itself from other React frameworks by strictly separating data sourcing from UI rendering through a unified data layer. Instead of fetching data directly in components using fetch or an SDK, Gatsby plugins source data into a build-time GraphQL API. This architecture makes it exceptionally powerful for "Content Mesh" websites that aggregate content from headless CMSs (Contentful, WordPress), 3rd party APIs, and local files.

  • Unified GraphQL Data Layer: Standardizes data access across your application. Whether the data comes from a Markdown file, Shopify, or a headless CMS, you query it exactly the same way using GraphQL.
  • Best-in-Class Image Optimization: The gatsby-plugin-image library is arguably the gold standard in the React ecosystem, offering automatic resizing, format conversion (AVIF/WebP), and blur-up placeholders with minimal configuration.
  • Performance by Default: Gatsby automates critical performance best practices, including route-based code splitting, prefetching resources for linked pages, and inlining critical CSS.
  • Deferred Static Generation (DSG): Allows developers to defer the build of non-critical pages until user request time, solving the historical problem of long build times for massive websites.
  • Massive Plugin Ecosystem: A vast library of plugins that abstract away complex configurations for analytics, sitemaps, RSS feeds, and CMS integrations.

Code Snippet

Gatsby pages are React components that export a GraphQL query. The framework automatically executes this query at build time and passes the result as a data prop to the component.

import * as React from "react"
import { graphql } from "gatsby"
import { GatsbyImage, getImage } from "gatsby-plugin-image"

// 1. The Page Component receives 'data' from the query below
const BlogPost = ({ data }) => {
  const post = data.markdownRemark
  const image = getImage(post.frontmatter.featuredImage)

  return (
    <main>
      <h1>{post.frontmatter.title}</h1>
      <p>{post.frontmatter.date}</p>
      {/* 2. Optimized Image Component */}
      <GatsbyImage image={image} alt={post.frontmatter.title} />
      <div dangerouslySetInnerHTML={{ __html: post.html }} />
    </main>
  )
}

// 3. Modern Head API (replaces react-helmet)
export const Head = ({ data }) => (
  <title>{data.markdownRemark.frontmatter.title}</title>
)

// 4. The Data Query
export const query = graphql`
  query($slug: String!) {
    markdownRemark(fields: { slug: { eq: $slug } }) {
      html
      frontmatter {
        title
        date(formatString: "MMMM DD, YYYY")
        featuredImage {
          childImageSharp {
            gatsbyImageData(width: 800, placeholder: BLURRED)
          }
        }
      }
    }
  }
`

export default BlogPost

This pattern allows components to declare their own data dependencies, ensuring that deleting a component also stops fetching its data.

Pros and Cons

No library is perfect; understanding the trade-offs is key to selecting the right tool.

Pros

  • Image Magic: gatsby-plugin-image handles complex responsive image generation better and easier than almost any manual solution.
  • Data Abstraction: The GraphQL layer decouples your UI from your backend. You can switch CMS providers without rewriting your frontend components, just the query.
  • Documentation & Community: Extensive documentation and a mature ecosystem mean most common problems (SEO, analytics, offline support) have "drop-in" plugin solutions.

Cons

  • Build Times: Despite improvements like Incremental Builds and DSG, building large sites (10k+ pages) can still be slow compared to Next.js or SSR solutions.
  • GraphQL Complexity: For simple sites, setting up a GraphQL schema and debugging queries can feel like over-engineering compared to a simple fetch call.
  • "Plugin Hell": Relying heavily on plugins can lead to "it works by magic" scenarios where debugging broken builds becomes difficult due to conflicting plugin versions.

Comparison with Other Frameworks

The table below outlines the positioning differences between Gatsby and other popular React frameworks:

LibraryDesign PhilosophyBest ForPain Points
GatsbyData-First
Everything goes through GraphQL. Prioritizes static assets and image optimization.
Content Sites
Marketing sites, high-traffic blogs, and e-commerce catalogs.
Build Time
Waiting for CI/CD pipelines on large sites; GraphQL learning curve.
Next.jsFlexibility-First
Hybrid rendering (SSR/SSG/ISR) with direct data fetching freedom.
Web Applications
SaaS products, dashboards, and dynamic social platforms.
Manual Optimization
Requires more manual setup for the level of image/font optimization Gatsby gives for free.
AstroHTML-First
Islands architecture that ships zero JS by default.
Static Content
Content sites where interactivity is sparse.
React Interop
React is a second-class citizen; state sharing between islands can be tricky.

Verdict: When to Adopt

Choose Gatsby if you are building a content-rich website (like a corporate blog or marketing site) that sources data from a headless CMS and requires top-tier image optimization with minimal effort. It is less suitable for highly dynamic, user-dashboard style applications where Next.js prevails, or ultra-lightweight static sites where Astro might offer better raw performance.