What are best practices for Gatsby Build/Release based on Content Updates in the CMS?

This question is posted on behalf of a user.

Moving content into the build+release process offers us a lot of new options + features, but I can see it also being an issue for clients if it's not performant.

Each save/publish in Agility causes a new content update, and that now has to be built every time, which can easily stack up and slow down.

Any suggestions/best practices for getting the best possible performance on builds and releases of content?

I've set up build+release pipelines with the gatsby and netlify CLIs in our DevOps that trigger on every save/publish. It takes around 30 seconds to get content built and updated; and that will get worse as more content/pages are created.

With a trigger every content update as well (imagining if someone saved/published 100 items at once), it can do a lot of useless builds too.

One answer is to beef up the VMs running the builds, though are there any other ways to speed things up that you've found ? How does your process look for content updates ?



  • Official comment

    Our Recommendations:

    • Setup Preview via Gatsby Cloud so that every Save (only, not Publish) fires a webhook to rebuild the preview environment - this should result in your preview environment being updated within 1-5 seconds
    • If you are using the Netlify integration through Gatsby Cloud, then you can simply set up a webhook to fire on Publish to rebuild the production environment
    • If you want to have a stage AND production server (static build), then, unfortunately, Gatsby Cloud Netlify integration only gives you one production environment - you would need to set up your own stage/prod static build pipeline in something like Azure Dev Ops or github actions
    • If you are designing your own pipeline, you need to ensure that the webhook you setup if smart enough to cancel a currently running build if a new build request comes in - this ensures that only one build completes per multiple publishes that might be taking place - this is KEY to ensure you don't queue too many builds. Gatsby Cloud does this by default, so you get this for free, but if you are using your own custom pipeline, you'll need to build this logic in. For Azure Dev ops, we find using an Azure Logic App is the easiest way to manage this and you don't have to write any code.

    How works:

    • On Save, a webhook rebuilds the preview environment in Gatsby Cloud within seconds
    • On Publish, a webhook hits Gatsby Cloud and rebuilds production, this is using what's called an incremental build (which is still somewhat experimental), but results in super-fast build times even for larger sites
    • When the production site is rebuilt, Gatsby Cloud automatically deploys this to Netlify
    Comment actions Permalink
  • In addition to the comments above: 

    One of the things that’s pretty new for Gatsby, but works really well, is Incremental Builds.

    Getting this going is a little tricky, but not that tough.

    • Make sure Gatsby is on 2.20.4 or higher (npm install gatsby@latest)
    • Make sure the public and .cache folders are persisted between builds
    • Add the flag to enable Gatsby incremental builds
      • Here’s the node script command:

    "scripts": {
          "develop": "gatsby develop",
          "build": "GATSBY_EXPERIMENTAL_PAGE_BUILD_ON_DATA_CHANGES=true gatsby build --log-pages"

    I adapted this from the Netlify blog here:


    Comment actions Permalink
  • Joel Varty for context, how many pages is and how fast is the build time with incremental builds?

    Comment actions Permalink
  • About 500 pages.  Regular build takes between 40-60 seconds. Incremental build takes between 4-6 seconds.

    Comment actions Permalink

Please sign in to leave a comment.

Didn't find what you were looking for?

New post