As I found out while chasing a 100 performance score in Lighthouse for my Jekyll website, performance optimisation takes effort. It involves a number of tasks, many of which are non-trivial to implement.
Relying on Jekyll and friends to do jobs more suited for a task runner like Gulp was slowing the build. Armed with this knowledge I started stripping down Jekyll to one of its core purposes - converting Markdown files into HTML.
… Decoupling the asset pipeline from Jekyll and Gulp-ifying it made the biggest splash in terms of build time.
People have come up with ways to … have a full asset pipeline inside Jekyll and perform other post-processing tasks. I would argue that while it’s nice to have one tool do everything, they sit outside the scope of what Jekyll should be trying to do. Grunt and Gulp will perform much faster for these tasks and already have a huge library of scripts you can use.
With my Twitter feed full of people talking about GatsbyJS, I decided to take a look and see what all the fuss was about.
Build with React
Bring your own data
Gatsby allows you to build sites with data from many sources: headless CMSs, content APIs, or file systems. This is advantageous as it allows a Gatsby website frontend to be decoupled from the content.
Data sources are set up using Gatsby’s data plugins, and data is pulled in using GraphQL queries.
Performance by default
Gatsby takes care of most of the work involved in building a fast website by following an architecture developed by Google called the PRPL pattern:
- Push critical resources for the initial URL route.
- Render initial route.
- Pre-cache remaining routes.
- Lazy-load and create remaining routes on demand.
In other words, Gatsby builds websites that start as static sites but become Single Page Applications. This helps achieve a fast initial load and instantaneous page navigations.
Gatsby also provides several image optimisation techniques, such as responsive images, placeholder images, and lazy loading.
The result is a static site generator that builds blazing fast, highly optimised websites by default.
Building with Gatsby
The above reasons convinced me to rebuild my site using Gatsby.
Rather than create a new site from scratch, I chose to use a Gatsby starter. As all of my content is in Markdown files, I needed one that uses the file system plugin.
My existing host, GitHub Pages, does not build sites that use a static site generator other than Jekyll. This means that Gatsby sites must be pre-built and pushed to a GitHub repository.
I wanted my site built on a server instead of locally, and prefer to keep build output out of source control. I had heard a lot of good things about Netlify, so this was an opportunity to try them out.
Deploying a site with Netlify is as easy as their website says: connect your repository, add build settings, and deploy your website.
Here are the Lighthouse results for my new website, built with Gatsby and hosted on Netlify.
The performance score of 99 is less than the previous 100 but the comparison is not like-for-like as it does not account for the change to a site design that is more image heavy. A more accurate comparison would be between my Gatsby starter, gatsby-casper, and its Jekyll equivalent, Jasper2.
One place I haven’t yet been able to use Gatsby’s responsive images is for the hero images for each page, which are displayed via the
background-image CSS property. This is causing the Properly size images audit failure.
I’m very happy with the move to Gatsby. Building with React and webpack lets me work with a modern tech stack, and Gatsby’s ability to pull data from anywhere using GraphQL gives me the freedom to separate my content source from the website code.
Gatsby’s biggest selling point, however, is its built-in performance optimisations. Using Gatsby saves me creating and managing a build pipeline to optimise my site and assets - it’s all done out of the box. For web performance by default, Gatsby is a game changer.