A Different Case Study: Bejamas.io Under The Spotlight

Why change Thom? What did we do wrong before and why?

What was the previous stack we used? What problems did we have with it?

Gatsby as static site generator, Contentful as headless CMS for our blog, and Netlify for hosting and deployment. Nothing wrong with the stack really. We’ve used it on a few more projects. But, as I mentioned already, we were using Gatsby v1.x version and it needed an upgrade to the latest version. Gatsby is moving fast, fixes bugs, and improves performance on a daily basis and with each day we were more and more behind.

We were using too many 3rd-party scripts we didn’t really need, JS-heavy animations, etc. All of these issues influenced not only performance but also UX and we needed to change that.

What is the tech under the Bejamas hub today?

Overall Gatsby, Forestry as headless CMS to manage our content and Vercel for smooth deploying. On top of that, we used Cloudflare Workers to cache static third-party scripts. In case you are not familiar with it, it rewrites the HTML to replace the third-party script URLs with URLs that are proxied through the origin and appends a content hash to the URL.

The goal was to create as the light of a website as possible, but still, have a web-app experience like instant route transition. In the future, we would like to add more reactive components. That’s why we bet on (p)react from the very beginning. Thanks to SSR offered by Gatsby out of the box, our website works perfectly even with JS disabled.

Many websites use Gatsby today, but not all of them have good benchmark results. How did we achieve ours?

As many devs know it is easy to create a huge bundle of JavaScript. I’ve seen a lot of small websites and apps shipping hundreds of kilobytes of JS. To be clear, it is not specific to Gatsby-powered projects. It was something we couldn’t afford. In order to keep First Contentful Paint, Meaningful Paint, Time to Interactive, and other performance metrics in shape we started the development phase by setting Performance Budgets.

Not sure how many are familiar with it but the overall idea is to set goals early so that you can better balance performance without harming functionality and/or user experience.

[
  {
    "resourceSizes": [
      { "resourceType": "document", "budget": 40 },
      { "resourceType": "stylesheet", "budget": 15 },
      { "resourceType": "font", "budget": 30 },
      { "resourceType": "image", "budget": 300 },
      { "resourceType": "script", "budget": 80 }
    ]
  }
]

Utilizing performance budgets in this build helped us to keep good performance through the whole process. We wanted to reduce everything we could - fonts, images, sections, 3rd-party scripts and keep just the essence but still, have a unique feeling of the brand.

We also used Linaria for CSS as it creates almost 0 bytes of runtime JS, but provides a good CSS-in-JS experience. It comes with some downsides, but we’ve handled those easily.

To save a few kilobytes more of JS we switched from React to PreactX. It’s not released as a stable version yet but has been working pretty stable for us.

We cut an additional 5kb by using the react-head. It may not be as advanced as a popular react-helmet but it has everything we need to manage SEO-related head tags. In case you want to use it in one of your projects we’ve created gatsby-plugin-react-head to make it easier for you.

Finally, we decided to use Vercel and Cloudflare CDN this time.

Why Vercel?

There are a couple of reasons as to why but one stood out: Vercel + Cloudflare supports Brotli compression. Now, we tested both gzip and Brotli compression, and in our case total transferred size of files compressed with Brotli is approximately 14% smaller than gzip. Since in this project we’ve been very radical about optimization Brotli was a clear winner.

Why the change of headless CMS?

We changed headless CMS from Contentful to Forestry. Over time, and a lot of projects, we had a chance to work with several different API and Git-based CMSs. For a project like this, where we did not have to create hundreds of posts and rebuild the website every 2 seconds, Git-based CMS (Forestry) is a far better option.

Personally, I love that I can edit content in Visual Studio Code and push changes through git. At the same time, we have a nice CMS editor for our marketing team.

Speaking of which, what are your impressions of Forestry UI?

The biggest challenge you had while doing this project and how did you overcome it?

Finding a good and low runtime cost CSS-in-JS solution was challenging. We’ve been using styled-components in most of our projects so far and we really love it. The runtime cost of v5 is around 12kb min + gzip. I was curious if we can get rid of it. After some research, I discovered linaria and astroturf. Both claim to be “Zero runtime CSS-in-JS” libraries. We made a bet on linaria and so far it does its job.

Was there anything about the implementation/results that surprised you?

I’m really stunned by how Gatsby improved DX and built an amazing community over time. V1 had a lot of bugs, weird behaviors, and a lack of stability. V2 brings pleasure to the development process.

Finally, your general opinion of the ‘stack’ combo that you were using in this particular project? The good and the bad sides?