What Professional Gatsby Users Want

As Gatsby continues to be used for building larger and more complex sites, we are constantly asking our users and the community how we could improve.

Earlier this year, we spent a bit of time talking to developers using Gatsby in larger organizations — over a hundred employees, and often into the thousands. We’ve seen hundreds of these organizations launch sites on Gatsby in the last few months, from government agencies (cia.gov) and Fortune 500 companies (jbhunt.com, nucor.com) to recent IPOs (affirm.com)

Among these professional Gatsby developers, we tend to hear less about specific bugs and feature requests and more about qualities they want and need in their site — faster load times, shorter publish times, and so on. They are focused on learning and applying best practices. 

If you consider yourself a professional Gatsby user, we wanted to share what we’re hearing, and what we’re working on, that’s specifically tailored to you. The feedback below is grouped into two categories: desires we heard from more than 15% of people, which we called Top Requests, and desires we heard from 8-15% of people, which we called Other Frequent Requests

Top Requests

Faster site performance. We heard a number of stories about Gatsby sites starting out fast, but slowing down as they became more complex with large Javascript bundles, abundant images, and marketing analytics. Performance is often a key business stakeholder concern.

Shorter publish times, especially image transformation cost during builds and deploy times. For larger sites, publish times are a friction point in team workflows and dissuade users from fully adopting gatsby-image. 

Better integration with core e-commerce functionality. Right now, users building Gatsby e-commerce sites overwhelmingly choose Shopify, and the most common ask was a smoother Shopify + Gatsby integration. Users wanted faster full builds, access to incremental builds, previews, and access to additional Shopify APIs, as well as a seamless cart/checkout experience.

Smoother growth marketing workflows. Marketing users often feel friction in workflows like building landing pages, integrating analytics & forms, and A/B testing compared to the CMSs they are used to. This can create tension in the organization between marketers and developers. 

Other frequent requests

More types of access control for Gatsby Cloud. A number of folks wanted the ability to access Gatsby Cloud through broader methods: SAML-based SSO, email / Google auth, Bitbucket, on-prem VCS (Github Enterprise), and so on. 

Clearer path to build a Gatsby practice within agencies. Agencies tend to encounter a number of unique steps in adopting Gatsby, such as testing Gatsby out on an internal project like their homepage, creating collateral and formally pitching to clients, pricing Gatsby projects, billing transfer for Gatsby Cloud, creating project templates, or growing internal expertise. 

Better integrations for “auxiliary” e-commerce features. The “long tail” of e-commerce functionality often lives in different systems: loyalty, product info management (PIM), subscriptions and installment payments, affiliate marketing, returns, and so on. 

Currently, it’s possible to integrate these extra systems, but can take additional time compared to integrating them into a “full-stack” solution like Shopify. Users wanted more of a turnkey integration experience for this functionality.

Smoother intra-site and cross-site Gatsby rollout. There tend to be two kinds of gradual adoption: first, gradually moving over pages & sections within a single website or, second, scaling Gatsby usage across a number of websites. 

For gradual adoption within a site, tech leads need to make a number of micro-decisions in creating a migration plan — for example, which templates or pages should be moved over? And in what order? When growing from one to several Gatsby sites, Gatsby users confront questions around code reusability: should they use a monorepo? Component library? Gatsby themes? In addition, they often faced challenges associated with scaling a team.

Less friction building and maintaining a component library. Component libraries play a part in almost every Gatsby site build. Along the way developers encountered a number of friction points, such as refactoring insufficiently or overly abstracted components, package and versioning management, and configuring their component library and headless CMS to work with Gatsby as a drag-and-drop landing page builder.

Recruiting & training developers. Organizations using Gatsby that aren’t startups or tech companies often reported adjustments in their hiring process — rather than looking for specialists in particular technologies, they started focusing more on generalist software developers. Other organizations, like agencies, with rapidly growing Gatsby usage reported needing to hire more people in a shorter timeframe than typical. 

More out-of-the-box i18n. Users report being confronted with a multitude of different ways to handle key concerns (routing, redirects, querying data). They often end up hand-rolling significant parts of their own solution.

Easier dynamic data, auth and routing. We heard a number of examples of friction; users finding client-side routing APIs unintuitive; falling back to proxy-level configuration to implement dynamic routing, workarounds to prevent content flashes on auth-gated routes, and so on. In addition, use-cases like scheduled content go-live times for regulatory purposes, product launches, etc are possible but unintuitive to implement. 

What we’re doing

We care deeply about our community, and enabling users to push the boundaries of what’s possible with Gatsby is a top priority for us — always.

If you joined us at  GatsbyConf last week, you saw our latest feature launches:

  • E-commerce: We shipped a new Shopify source plugin which is dramatically faster and more scalable. In addition, our new gatsby-plugin-image is a huge boon for image-heavy e-commerce sites. 
  • Preserving key marketing workflows: We shipped WPGatsby 1.0, which enables previews and incremental builds on Gatsby + WordPress websites.
  • Build times: Gatsby Cloud has the fastest build times in the land. However, with deploy times becoming a bottleneck, we just shipped Gatsby Cloud Edge CDN. The new Gatsby 3.0 has significantly shorter build times, especially for large sites. 

And smoothing these paths isn’t just about shipping new features. We’ve been surfacing success stories and emerging best practices in each of these areas:

These aren’t the end — just the beginning. In the coming months, expect new releases, case studies, documentation, and events on a lot of these topics. 

And if you’re working professionally on Gatsby sites and any of the points above resonate, we’d love to hear more. One thing we’re trying over the next couple months is holding small-group discussions (like the breakout sessions at pre-pandemic Gatsby Days) around each of the topics, then surfacing the lessons & learnings from these sessions to the community. Just fill out this form and we’ll reach out.