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:
Before we get to how we did it, let's dive into the 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:
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.
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.
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.
<Link /> component on each page. This is the bread-and-butter of what makes sites built with Gatsby so snappy!
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:
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.
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%.
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 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.