If you follow me on Twitter, you’ll know that my November project was to rebuild my personal site using GatsbyJS and the WordPress.com API:
November's project: Rebuild personal site in @gatsbyjs using the https://t.co/ckkv8VVxPp API. Started this morning! pic.twitter.com/rq5swzyp2Q
— Jeremey DuVall (@JeremeyD) October 27, 2017
If you’re not familiar with Gatsby, it bills itself as a “blazing-fast static site generator for React.” Having used React to work on Calypso and build some other small projects here and there, I figured it would be a pretty fun experiment.
Obviously, November has come and gone, and yet, you’re still seeing a traditional WordPress theme on my personal site. I ended up not launching my GatsbyJS site (although it is more or less built!) for a few reasons. I’ll touch on those reasons as well as my experience working with GatsbyJS.
Why use GatsbyJS in the first place?
First, let’s talk a bit about why anyone would replace the frontend of their site with React instead of a traditional WordPress theme. There were two primary reasons for me.
Speed
GatsbyJS gives you server-side rendering by default, and it preloads resources at build so clicking around the site is insanely speedy. For example, if you run my current site, which is pretty minimal by most standards, through a speed test on Pingdom, you’ll get somewhere in the neighborhood of 1.33 seconds with a grade of 89. Not too bad!
Now, let’s take a look at my personal site that I wrote with GatsbyJS and deployed on Netlify.
It loads in 382 ms and gets a grade of 100. If you run it through Google PageSpeed Insights, it will get a grade of 99 on mobile and 100 on desktop.
One reason GatsbyJS is so fast has to do with how the page is loaded. Whenever you load a new page in a PHP-driven, traditional WordPress site, every new page load requires a request and response from the database. Depending on how many assets you’re loading and how big the request/response is, it can slow down the page load quite a bit.
With GatsbyJS, a few things are happening on the backend. First, when you build your site, Gatsby uses the WordPress.com API to fetch all of the posts, pages, custom post types, etc that you might need to display your site. It’s really easy to do this using the Gatsby Source WordPress plugin.
Once it has all of the data, it pre-builds all pages and posts on your site at build time. Using the templates you write, Gatsby creates all routes so they’re ready to go. You can see this take place if you run gatsby build on any Gatsby project. You’ll see a new list of files under /public that will have index.html templates for all of your routes.
The result is that when you deploy on something like Netlify, all of your pages and assets are ready to go. Clicking around is instantaneous because everything is already there. It also has some built-in image optimizations that are pretty nifty and fast.
Experimentation
The second (and more personal) reason that anyone would use GatsbyJS is just to experiment with new technologies. I work for Automattic so I have a heavy investment in wanting WordPress/WordPress.com to succeed. I believe there’s a lot to be gained from experimenting, learning from, and when appropriate adopting new technologies like Gatsby.
Coming from a code background primarily in JavaScript, I also enjoyed being able to build my own layout and templates in React. I can work through PHP, but I’m much more comfortable with JS frameworks.
Why I didn’t stick with GatsbyJS for my personal site
The darn thing is pretty much built except for adding in meta tags to the header on individual pages for social networks and such, but I decided to stick with a traditional WordPress theme for a few reasons.
First, I’m excited about the upcoming developments in the WordPress editing experience. If you watched the State of the Word with Matt at WordCamp US this past weekend, you saw some of the powers behind Gutenberg. Moving the frontend of my site on to a static site generator like GatsbyJS meant I would miss out on some of those aspects. I really think Gutenberg is moving WordPress in the right direction, and I want to be a part of pushing that forward.
Second, there are a lot of aspects to WordPress that you take for granted like category pages, easy searching, contact form plus validation, etc. Those are certainly possible with Gatsby, but you have to build them yourself. Sure, it’s not that hard, but there’s an aspect of maintaining/testing that you don’t necessarily have to deal with on WordPress.
The third reason had to do with WordPress.com. Ideally, I would’ve set up a free site on WordPress.com, enabled a custom post type for my bookshelf, and added some custom meta fields to the post type that I could then use for rendering them. It’s not possible to setup custom post types on free WordPress.com sites at the moment, which meant I had to treat books as a different post format to distinguish them. It’s certainly not impossible, but again, some of the use cases I was looking for made more sense with WordPress.com than with Gatsby.
Wrapping Up
I do think GatsbyJS offers some really unique tools, techniques, and selling propositions for a static site generator, and I do want to build plus launch something using the WordPress.com API plus GatsbyJS. I just didn’t want it to be my personal site.
Instead, I’m going to build an Instagram clone to share photos. I’ll do a full series on that for anyone interested in learning how you put one of these sites together using components, templates, etc.