We’ve started hosting regular Gatsby community Q&A chats with yours truly! The last one was on March 6th and the next one is scheduled for early May. They’re great fun to chat with the folks about things that are on their mind and talk about ongoing/upcoming work.
The full video is on YouTube & I’ve written up many of the questions & my answers below.
In 2018 you blogged about “a new version of Gatsby” with incremental and parallelizing builds—what’s the status & roadmap for incremental builds with Gatsby?
I’m guessing this question is referring to my blog post on the launch of our company in 2018 and that supporting very fast deployments for everyone is our top goal as a company.
This has always been my goal with Gatsby. The Gatsby v1 architecture was designed specifically to support this. Here’s the original tweet announcing when the basic support for incremental builds was added to the framework in a 1.0 alpha:
Gatsby has always used “incremental building” to drive developing on sites. When you edit a markdown file, Gatsby “incrementally” updates just the pages affected by that change to the markdown file.
The Gatsby cache, if saved between builds, also substantially increases the speed of builds by avoiding much of the rework.
As most of you know, we recently launched our own continuous deployment product on Gatsby Cloud. Included in that was initial support for parallelizing parts of the build process — images to start with, and more to come.
That drove some impressive improvements to build speeds:
- Third and Grove saw 60x build-time reductions from 60 minutes to 1 minute for their large 15,000 page, image-heavy Gatsby/Drupal site.
- Gatsbyjs.org saw 9x reduced build times from 45 minutes to 5 minutes.
- Our image processing benchmark site saw 5x reduced build times from 200 seconds to 40 seconds.
We’re working on a dramatically improved way to cache between builds (making builds even more “incremental”) that’ll make all site builds a lot lot faster. We’ll be making more noise about this soon as we ready it for launch.
We want to make consistent < 10 second deploys a reality for everyone and any type of site & we’re very focused on making that happen.
SSR (server side rendering) support is really critical for React websites. By default, React only runs in the client so it doesn’t support bots from Google and social media sites, which hurts SEO and social sharing.
There are two flavors of SSR — build-time & run-time — both solve the problem of SEO/social sharing.
Gatsby has had build-time SSR support from the our first release in 2015. So Gatsby has always been a great choice for React apps that need SSR support.
Some people ask us to support runtime SSR as well. We often discuss doing that but have always to date decided to instead redouble our efforts to improve build-time SSR as frankly, it’s a lot better for everything.
Build-time SSR is incredibly less complex than runtime SSR. Operating build-time SSR sites is trouble free — you just build the site & push it to a CDN and don’t need to think about it anymore. Run-time SSR means you need running Node.js web servers to render the site…which means you have a lot of running code that can break, get overloaded, get memory leaks, and break in any number of other ways.
People tell us one of the main things they love about Gatsby is they sleep a lot better at night.
They don’t get alerted about website problems.
The only problem with build-time SSR right now is when builds are either not fast enough or can’t scale to the size of your site.
We’re razor focused right now on solving these two problems (see the last answer). We’re working so that you can build any size of site (millions of pages+) with Gatsby & deploy incremental changes in under 10 seconds.
There are still two remaining valid reasons for run-time SSR that we plan to support. One is personalization where the page needs to be customized for the visitor based on a variety of factors. The other is A/B testing. Both of those require that you can render custom versions of pages on the fly. We will not only support this but also solve it in a way that doesn’t sacrifice the speed and simplicity Gatsby is known for.
A bit of back history for everyone: last year we hired Jason Bahl, the creator of WPGraphQL, to continue his work. We want to fully support WordPress + Gatsby, meaning content authors can see real-time previews and content changes deploy in less than 10 seconds. This is the great experience that CMSs provide for content authors. Replicating it is a hard requirement for most people considering moving to a headless WordPress + Gatsby stack.
We choose WPGraphQL as the way forward as Jason’s done an amazing job making incremental querying incredibly fast—as well as adding GraphQL subscription support, which will drive both preview & incremental builds.
Last fall Tyler Barnes — a long-time Gatsby/WordPress developer — joined the team to work on a new version of gatsby-source-wordpress that leverages WPGraphQL to drive preview/10 second deploys.
They’ve been making incredible progress. Check out the umbrella issue for the epic. A number of people are experimenting with the alphas and even shipping sites! If you’re interested in this space, please dive in.
Working with images is a pain, and the distinction between page and static query seems a wrong API. The issue #10482 seems to fix both. What’s the plan?
We’ve worked on a number of ideas/prototypes for solving this but haven’t yet arrived at something we feel is a genuine improvement. There are more ideas floating around for better APIs, so stay tuned. We’d love to pair with anyone who has ideas for improving things as well.
Yup! Once the new gatsby-source-wordpress version is ready, Preview & Incremental builds will work out-of-the-box on Gatsby Cloud.
We ship releases multiple times a week. Most are incremental improvements and bug releases. We periodically write blog posts summarizing improvements. You can catch up with them at https://www.gatsbyjs.org/blog/tags/gazette/
Lots more that we’ll be talking about soon.
Any plans for gatsby-source-drupal to support some kind of caching when retrieving thousands of nodes from Drupal?
Yup! We hired recently Shane Thomas to work full-time on improving Drupal + Gatsby to support Preview & Incremental builds just like WordPress and other CMSs.
A few, though we don’t anticipate it being a difficult upgrade. We’ve been collecting ideas in this issue (none of them are for sure yet) https://github.com/gatsbyjs/gatsby/issues/15277
Shadowing pages is difficult. Query collection gets in the way of shadowing pages effectively when using different data sources. Known issue? Being addressed?
Yeah — we’re not satisfied with the shadowing experience yet. One way we’re looking to improve the experience is with Gatsby Admin as you’ll be able to browse your themes and what files they have and immediately shadow one plus see the diff between your shadowed file and the original.
We’re also investigating better patterns for building themes to ensure they’re flexible and straightforward to extend/override.
Is there a limit on the size of a website generated with Gatsby? At what point does the build time become unmanageable?
We’re also working on adding benchmark sites that’ll show more clearly when a site is a good fit for Gatsby.
How do you make awesome documentation? I saw other projects but the documentation of Gatsby has a special place in my heart.
Awww thanks! I don’t know there’s anything magic other than just caring enough to do it. Like doing anything else great — you have to care and put in a lot of effort. The whole community and internal folks leading the effort, like Marcy Sutton and previously Shannon Soper, have done a ton of work to improve the docs over the last few years.
Yes! This is something we’re pretty excited about shipping. If you’re interested in learning more or helping out, check out this issue Sidhartha Chatterjee put together — https://github.com/gatsbyjs/gatsby/issues/18983
Are you continuing to work on even more good accessibility defaults for Gatsby in the future? How important is accessibility overall within Gatsby?
Check out our blog posts tagged with accessibility: https://www.gatsbyjs.org/blog/tags/accessibility