How to make your Jekyll website blazing fast!

A few years back I used Jekyll and Github pages to create a one page CV/resume template site, it turned out to be one my most forked Github project and the blog post I wrote up about it one of the more popular articles here.

So recently, when I was looking to create a site about food science, I thought I would have another look at Jekyll and Github hosting. One of the things I knew I wanted was a nice dynamic site, but one that was really quick and that I could really optimise for SEO, and I was confident that Jekyll would deliver on that front (I mean, its a static site generator, so it builds full HTML to be served in one, so no overly heavy or slow client side stuff needed).

I quickly forked a Jekyll project, added a couple of old posts to test the content and gave it a whirl (serving it directly from the Github pages URL) - out the box I had a nice clean site, already mobile responsive, so time to see how it performed!

A quick test on the Google Page Insights (formerly Lighthouse), and straight out the gates it was scoring pretty well - but there were some sensible recommendations within the results, that made sense to implement.

Serve images in next-gen formats

I was using reasonably sized jpg images for the most part, but there are further optimisations available in the form of using webp formats. Quickly grabbing the cwebp CLI tool made it super quick to convert all my images over to webp. I had to update the image HTML a little to support webp whilst falling back to jpg where browser support dictated as so:

The above basically just sets the source of the image as the webp variation of the file and falls back to the jpg if webp is not supported.

Google font optimisation

My basic jekyll template I was using relied on Google webfonts, which presented two different performance issues:

1. Flash of invisible text (FOIT) - A while ago, Google introduced a change to the CSS loading snippet for their google fonts, with the addition of the query param “&display=swap” on the end of the CSS URL.
   This small change, broadly supported by modern browsers, basically fixes the FOIT and instead falls back to a flash of unstyled text (FOUT) - so on slower connections whilst the font is loading, there is at least content displayed, albeit not as pretty as you’d like (there is a cool tool here to compare fonts, which you can play with to try and find a native font that isn’t too much of a leap from your google webfont, so the experience isn’t too jarring).
   This improved my Page Insights time to First Contentful Paint as stuff on the page.
   
   
2. CSS loading synchronously so still blocking page load time - thankfully people have solved this through a variety of tricks and techniques - moving the CSS load to async and also utilising preconnect and preload to warm up the end points (a very detailed write up can be seen here!)