Will It Build?

Build your next site with Gatsby

In the past, websites that required rapid data updates or had a large number of pages or media defaulted to an architecture focused on runtime rendering. With recent advancements in Gatsby Core and the introduction of Incremental Builds in Gatsby Cloud, developers can now adopt Gatsby for their most ambitious projects.

Will It Build tracks the progress of build times for Gatsby benchmark sites, providing historical data for build times on Gatsby Cloud across several popular CMSs and content sources. The build time calculator provides an estimation of build time across each of the build types used in Gatsby Cloud. Together the build time calculator and benchmark data help developers determine if Gatsby is a good fit for their next project.

Frequently asked questions

Can't find the answer to your question? Talk to us

No. Will it Build focuses exclusively on Gatsby applications.

Definitely! Our public API can be accessed through our GraphQL playground. You can get as granular as you’d like with the raw data powering Will It Build.

Additionally, we have open-sourced all of our example benchmark sites as well as the benchmark plugin that reports back data.

Our calculator relies on the same data as the rest of the Will It Build project, but categorizes it in a way to make it easy for you to estimate how long your project might take to build.

Sign up for Gatsby Cloud and run your first build today!

Gatsby was open sourced nearly five years ago, and since then hundreds of thousands of people have used it to build for the web. In that time we’ve learned a lot about making builds fast and are now applying that knowledge on Gatsby Cloud. There are three ways we make builds faster:

  1. Optimize individual operations. Build systems do many things. Reducing individual operation times will lead to faster builds. We’ve spent years improving Gatsby’s complex build system to optimize it from beginning to end. This includes many contributions to upstream open source projects that benefit the broader web community.
  2. Distribute more work. Even if individual operations are very fast, the overall build can be made even faster by distributing individual operations across many machines.
  3. Intelligent Caching. By tracking dependencies between operations and their outputs Gatsby Builds intelligently avoids re-executing redundant parts of the build.

You'll notice that data changes for CMSs are the fastest builds by far. That's because they're using Incremental Builds in Gatsby Cloud. Incremental Builds only rebuild the data that's changed, reliably giving you <10 second builds on most data changes, no matter how many pages your site has.

Ultimately we want all Gatsby builds to be fast, wherever they run. Because we can optimize the build process specifically for Gatsby in Gatsby Cloud, all Gatsby builds--incremental or standard--are anywhere from 10-1000x faster than other non-specialized solutions.

We created a series of benchmark sites to simulate Gatsby sites of various sizes. We’ve done our best to produce a realistic workload, though the sites don’t have the aesthetic touches that real products do. Benchmark sites are open-sourced on GitHub here.

Contact partners@gatsbyjs.com for more information on how to add a benchmark to Will It Build.

We trigger two types of changes (a code change and a data change) and then we time the build time from the beginning of the Gatsby build process to finished build. For code changes, we record both the cached and uncached build times.

Yes! We have open-sourced all of our example benchmark sites as well as the benchmark plugin that reports back data. Additionally, all of our data can be queried with our exposed GraphQL API at willit.build/api-playground.

Different scenarios can lead to radically different build times. Not all updates are equal.

In Will It Build, we track 3 different kinds of updates:

  1. A data change, done through a CMS (For Gatsby Cloud, we use Incremental Builds for these types of updates)
  2. A code change, with an available cache
  3. A code change, without any cache (the first build)

A data change is a tweak made through the CMS (eg. Contentful). For example, when a content editor publishes a new article, or fixes a typo, this represents a content change, because the codebase hasn’t changed. Gatsby Cloud uses Incremental Builds to rebuild only data that has been changed, so most data changes reliably happen within 10 seconds. Incremental Builds are only available through this method as part of Gatsby Cloud's specialized tooling for Gatsby sites and apps.

A code change is anything that was pushed through source control (eg. Github). For Markdown and MDX content sources, all changes are considered code changes. Gatsby Cloud currently uses standard fast builds for code changes.

Will It Build supports several different content providers: most of them draw content from a CMS. This is considered a data change.

Our Markdown and MDX benchmarks are slightly different. The content is stored in the codebase, as files in the repository. This is how Markdown/MDX sites typically work and is considered a code change.

What isn't typical is that we re-generate all these files during the build. This is done for logistical reasons, because we store all benchmarks in our monorepo. This means that the time shown in our build metrics also includes the time spent generating the documents, which can be a significant amount of time for the higher page-count benchmarks.

Cached and uncached build times reflect what is available in Gatsby Cloud's free plan. Data builds are the equivalent of Incremental Builds in Gatsby Cloud and are part of Gatsby Cloud's paid plans. Developers can test out Incremental Builds in Gatsby Cloud for supported CMSs with a 14 day free trial, no cc required.