Adventures in Gatsby and Wordpress - Part 1

A Bit of Background

I'm run a small webshop called amillionmonkeys. It's mostly me building stuff flung my way by designers and agencies, but I occasionally rope people in. Like most people who have been doing this a while, I made a living from churning out wordpress sites for startups. Now I mostly build apps with Laravel and React.

Hotness

At the minute, it feels like everyone is talking about Gatsby. There's a whole load of reasons to be excited about Gatsby but for me it comes down to a couple of factors:

  1. Seperating frontend and backend for smaller projects While the big boys have long since had the resources to seperate their CMS and front end seperately, for smaller organisations with limited resources, this has never really been an option. The result, especially with Wordpress, has often led to massive page bloat.

  2. Bringing the bells and whistles to everyone In the traditional stack, best practise like lazy loading, image optimisation, progressive web app goodness and prefetching was at best a headache and at worst impossible. Gatsby comes with most of this stuff out of the box.

With this in mind I've been playing with Gatsby on smaller projects for a while and it's standing up well, especially using Netlify. But now I'm putting Gatsby through its paces, I'm trying to rebuild Cultbox with Gatsby. It's a wordpress powered professional blog, with over 16,000 posts, all tagged, all with stacks of images. This is going to be fun...

Initial Thoughts

A few general points about getting started building client sites with Gatsby:

  1. Learn from starters, don't copy them. The Gatsby site features a load of starters. My advice would be to examine the code for these starters and learn from them, but don't replicate them line for line. They make a lot of presumption about your backend, and a lot of code which makes their starters look lean, but add unnecessary bloat.

  2. GraphQL is a head fuck! I've spent years working with RESTful APIs and it totally makes sense to me. GraphQL is a totally different beast. If you're serious about Gatsby you need to dive deep on GraphQL or you're gonna hit a world of pain pretty soon.

  3. Use Netlify to host your site. Seriously.

  4. If you're migrating a Wordpress site, evaluate what plugins you're using. Cultbox has over the years used a handful of plugins to add features like polls, ratings and embedding ads and content. Switching to Gatsby means we either need to replicate that functionality or ditch those posts, I'm hoping for the later.

Gatsby at Scale

Where this gets interesting is not a lot of people seem to have done Gatsby at scale. One guy messaged me to say he built SendGrid.com with Gatsby and tested it with 30k posts, but I found few other examples with more than a thousand pages, and when including the category and tags pages Cultbox has, I'm looking at at least 20 times that number of pages. This is a different beast, so this post and subsequent articles will focus on the challenges and lessons learned from building a large Gatsby site.

Lesson 1: You're gonna need decent hosting

To get started, I downloaded the Wordpress Gatsy Starter updated the endpoint and hit go! This caused a world of pain. Cultbox is currently on some shitty shared hosting package and I took that down good and proper. Getting data out of Wordpress generates a lot of requests in a small amount of time. While I'm experimenting I'm now running the site locally and all is well. When we go into production, I'll probably host the site on Pantheon or something similar.

Lesson 2: Fetching Data: two routes but one winner

Although this might change in the future, when you build your Gatsby site, every page is regenerated. On Cultbox this is likely to be a few times every day and while this is never going to be instantaneous I would like to get it built reliably in a few minutes.

The recommended route for getting data out of Wordpress into Gatsby is gatsby-source-wordpress. This uses the Wordpress REST API which has been fully integrated into Wordpress since 4.7 (2016).

The alternative is to install WPGraphQL Wordpress Plugin and use that as a data source (using gatsby-source-graphql). You can find a working example of this at here.

I've created two sites, one using each technique. Out of the box, both of hang after a few minutes, I'm not really worried about that though, as this is hardly a typical use case. So for now I've stripped out all the boilerplate template and all I'm trying to do is create one page for each post, no image optimisation or any other Gatsby goodness just a basic page displaying the title and content.

import React, { Component } from "react"

class PostTemplate extends Component {
    render() {
        const post = this.props.data.wordpressPost

        return (
            <div>
                <h1 dangerouslySetInnerHTML={{ __html: post.title }} />
                <div dangerouslySetInnerHTML={{ __html: post.content }} />
            </div>
        )
    }
}

export default PostTemplate

With this refined approach, both sites build successfully. Creating all 16,297 pages!

Using the first technique which relies on gatsby-source-wordpress and the Wordpress REST API took 370.363 sec (just over six minutes). The second technique using WPGraphQL was much quicker– 218.88 sec (just over 3.5 mins).

Things might change, but so far using WPGraphQL seems to be much more efficient than relying on the Wordpress REST API.

Next up, Archive, Category and Tag pages, what could possibly go wrong!

Show Comments