Dark Mode in Clubhouse is here! Learnmore

How we used Gatsby, Prismic and Fastly to build a blazingly fast SaaS marketing site

Eli Perkins

In October 2018, we rolled out a new face of Clubhouse, with a new logo, new brand, and - one bit that I've been really excited about - a new marketing site. The marketing site - the site on which you're currently reading this post - is an integral part of the Clubhouse brand as it’s what most prospective users see before they sign up for Clubhouse. It helps them learn about our features, see what our customers say about the product, and discover other information about Clubhouse like pricing and FAQs.

We had a few goals in mind when building out this new marketing site:

  • We wanted to enable our marketing team to make changes rapidly, without needing to edit HTML or JavaScript.
  • We wanted to be able to easily add new types of content to the site (e.g. webinars, customer stories, press about Clubhouse), without having to design and configure a custom CMS interface each time.
  • We wanted to migrate The Clubhouse Blog to host it on the new site instead of  Medium.
  • We wanted to build beautifully-designed, shared components to use across the different pages and features we build.

Before we get to how we did it, let's dive into the old marketing site.

This Old Marketing Site™

Our old marketing site was a fairly trivial web application. The teaser-site, as it was called, ran on the following tech stack:

  • jQuery
  • Fastbinder for event binding from our templates to our JavaScript
  • Caveman for markup, a templating engine we use across our app
  • Less for CSS and styling
  • A few Grunt pipelines to tie these things together

The output ended up as a set of HTML files that linked to a single blob of CSS per page plus a global CSS blob, and a single bundle of JavaScript per page plus a global JavaScript bundle as well. We put the resulting build on a few EC2 instances, running nginx for vanity URLs and handling miscellaneous redirects, proxying and such. Those EC2 instances would belong to a load balancer that would handle and direct incoming traffic accordingly.

The old Clubhouse marketing site (2016 - 2018).

Our blog was hosted on Medium. We knew that, eventually, we would want to provide a more seamless user experience - and move away from a third-party owning and delivering our content. Medium provided us a way to create new blog content quickly while crediting different authors. This was especially useful to us in the early days of Clubhouse when we were trying to get the word out and encourage curious prospects to give us a try.

This stack grew with us fairly well over nearly four years. Most changes made over that time were a combination of editing some HTML, CSS and JavaScript to add some more content or tweak some copy. To make more substantial changes, a solid understanding of the codebase, from build pipeline to the underlying frameworks, was required. As our team grew, maintaining this site became the burden of one or two people, creating a bottleneck in how we got work done on the marketing site.

We knew we wanted to give the team more control over how the site looked and functioned, while still having a fast and flexible end result. Knowing that the Clubhouse rebrand would include a complete redesign of our marketing site, we set out to build a new tech stack that would grow with Clubhouse.

Enter Gatsby

We began working with Ueno, who designed the new face of the Clubhouse brand, to build our new marketing site. After evaluating a few different tools and paths, we decided that Gatsby was the best fit for our needs.

Gatsby is really great at building fast static sites out-of-the-box. It takes today's best practices for fast, modern React websites, pulling data in from whatever data source you bring to the table. The end result is a static site in a single directory that can be deployed to S3 or a CDN for optimal performance. By creating a static site — one containing a simple set of HTML, CSS, JS and other media — we can deliver these sites without a specific server or EC2 instance to run them (or “serverless” as the kids call it these days).

Gatsby allows Clubhouse developers to build the site from the ground up with custom React components. Since we already use React in our other applications, there's little overhead of learning a new paradigm or framework.

Gatsby has two really compelling features that helped us create a fast static site: code splitting and prefetching. Code splitting allows us to ship just as much JavaScript as needed for each page. No more ever-growing global JavaScript bundle to be loaded for each page. Instead, chunks of code can be delivered over an open HTTP/2 connection for optimal page load speed. Prefetching chunks allows CSS and JavaScript to be loaded on a per-page and per-component basis, and even better, to be lazy-loaded for each <Link /> component on each page. This is the bread-and-butter of what makes sites built with Gatsby so snappy!

After seeing other Gatsby sites in action across the web, like the new React documentation website and a few other blogs around the internet, we knew that we could build our new marketing site on top of this framework, making a speedy experience for prospective Clubhouse customers.

Enter Prismic

Once we knew how we wanted to present and build our site, what about making changes? To have total control over the presentation of our content, we chose to take an approach that wouldn’t prescribe any UI or markup. After evaluating a few options, we chose to use a headless CMS to allow for the team to make changes on-the-fly, without needing to dive into the nitty gritty of the code at all. A headless CMS, unlike a traditional CMS like Wordpress, is a content management system with no UI or rendering at all. Instead, it focuses on a simple authoring experience and exposes its contents via an API.

For our headless CMS, we chose Prismic. Combined with gatsby-source-prismic, we had Gatsby and Prismic connected in no time. Data sources in Gatsby are one of its most compelling features. Instead of our users’ browsers pulling in content from Prismic on every page load, Gatsby pulls data from Prismic at "compile" time (using Gatsby's <StaticQuery> component) when the site is being built. The data for each page is pre-packaged into the static site, resulting in pages that load near-instantly without waiting for extra HTTP requests.

Querying data that's stored in Prismic, from Gastby, using GraphQL.

For the content creators, using Prismic is straightforward. On pages where content and page structure is less likely to be frequently changed (e.g., the homepage), Prismic provides easy-to-edit fields. Since Prismic is a headless CMS, we define, using React components, how those fields should render. This leaves less risk of “breaking” the design with bad formatting decisions or mistakes.

For more repeatable page types (e.g., a blog post or customer story) our Prismic configuration uses Slices. Slices allow the author to add and format different content types (e.g., text, image, video, quote etc) as self-contained blocks on the page. These blocks can be added, deleted and moved throughout the page as the user sees fit. What’s great about Prismic is that content types and Slices aren’t predetermined out of the box: it’s really easy to add new ones through their custom types interface.

Adding a Slice in Prismic.

We're still learning about the best way to structure our content within Prismic but, after some fine-tuning, we've built a robust system of pages, custom types, and linked documents. This system allows any team member to add, remove, edit and update content on almost every page on our site, from full customer stories and blog posts to single call-to-action buttons. Content changes can be completed solely from Prismic.

Custom Types in Prismic.

Some things to note about using Prismic for your own SaaS or static website needs:

  • Right now, our Staging and Production environments use the same Prismic repository. This means that if we are testing any draft content on Staging, we have to unpublish it before deploying to Production. Prismic does have a cloning solution for this which we’re looking forward to using in the future.
  • Prismic doesn't have a content authoring workflow (yet), meaning any collaboration should happen elsewhere. We use Google Docs because it has version control, commenting, tagging and, of course, a nice Clubhouse integration.
  • Any headless CMS is definitely not an out-of-the-box website solution. By definition, headless CMSes are just that, headless, meaning without an outward facing UI! It's perfect for us since we have a great custom design for our marketing site, but it may not be suitable for those looking to get something up and running quickly.

Enter Fastly

After choosing a framework and where our data was coming from to power the site, we needed to determine how the site would be deployed. We learned a lot about using Fastly as our CDN for the Clubhouse web app in 2018 and saw some great performance metrics from our customers around the globe (more on this soon). We applied what we learned from that experience to our new marketing site. Since this site is 100% static content, each build of the site gets uploaded to S3 and deployed using Fastly as our CDN. Combined with the power of HTTP/2 and code splitting, the result is a Performance score of 90 from Google's Lighthouse audit.

This is really important because, according to Google, 50% of people expect a site to load in less than two seconds.

Gatsby + Fastly combined means our new marketing site loads blazingly fast.

This performance is reflected on mobile too. When it comes to mobile speed, every second matters – for each additional second it takes a mobile page to load, according to Google, conversions can drop by up to 20%.

With Gatsby + Fastly, the mobile version of our marketing site loads almost instantly.

Since changes to content in Prismic require a redeploy of the marketing site, we built a set of internal tooling around GitHub webhooks, CircleCI and Prismic. This allows for new builds to be deployed to a staging environment to be reviewed and then deployed to production. Each deploy of the site flushes the CDN cache, meaning changes to the site are delivered to our customers instantly.

The New Clubhouse.io™

The end result is a speedy, shiny site that allows our marketing team to tell Clubhouse's story to our prospective customers. Go ahead and click around the different parts of our site. See how little time various blog posts take to load, and how quickly you can navigate among our feature, pricing, careers, and customer stories. Go ahead, I'll still be here when you're ready to come back.

Diagram of our marketing site tech stack

I'm really excited about how this tech stack will grow with Clubhouse. We've already built new features upon it, such as the new Webinars & Training page and pull request preview deploys for reviewing changes to the marketing site.

We're all-in on Gatsby here at Clubhouse. It helped us build an amazing and fast site. A big thank you to Birkir and the rest of the team at Ueno for helping us getting it all off the ground. Birkir is doing some really interesting work with React, Gatsby and Prismic, all of which you can find here.

Have you used Gatsby and/or Prismic and want to share your experience? Let us know on Twitter! Want to learn more about how we use Gatsby, Prismic, Fastly and more? We're hiring!