I’ve now built three sites using the Jekyll static site generator (including my personal site) and have hosted two of those sites using the free GitHub Pages. Overall, I’m really happy with the amount of control and performance benefits a static site generator provides.
With an increased focus on performance in the web industry, I wanted to see how well I could perform against Google’s PageSpeed Insights test. With some minor tweaks, I was able to score a 98/100 on Mobile and 97/100 on Desktop for my personal website. I’ll explain why I couldn’t receive the full 100% later.
I like to keep my development stack as simple as possible - so I am not using any Grunt or Gulp workflows for my static sites. The steps below won’t reference any automatic image optimization or minification, although these are certainly viable options as well.
USE RESPONSIVE DESIGN BEST PRACTICES + SIZE TAP TARGETS
The User Experience steps are typically the easiest to complete. Make sure you’re:
- Not using Flash or Java
- Sizing touch targets appropriately and spacing UI elements out
- Using legible font sizes
- Configured the RWD viewport
Google takes off points for any “blocking” scripts, so place your scripts at the end (before the end of the body).
Additionally, you could take advantage of the “async” attribute to ensure your script loads asyncronously, although this may not be necessary.
ASYNCRONOUSLY LOAD CSS
I’m using the loadCSS function from Filament Group to asyncronously load all of my CSS. Otherwise, Google will dock you for blocking CSS behavior.
INLINE CRITICAL CSS
Inlining critical “above-the-fold” CSS ensures users can begin interacting with the page faster and also helps prevent the flash of unstyled content (FOUC). There are of course ways to automate this, but I used this Critical Path CSS Generator. I did have to modify the CSS to include more styles, based on a repeat test.
From my tests, Google checks images to ensure they are both sized correctly (you’re not displaying images smaller than the needed dimensions) and that they’re losslessly compressed. Again, you could do your compression and sizing with a task runner, but I opted to use the ImageOptim app for Mac. It looks like every JPEG and PNG file must be losslessly compressed in order to pass. Additionally, you might use Responsive Images to provide multiple sizes of the same image (although I do not think this is required).
USE A CDN (CLOUDFLARE)
By the far the more efficient way to increase your score is to use a free content delivery network to serve your site. I recommend the free version of CloudFlare because of its simplicity. There are a few reasons for this:
- GitHub Pages by default places a caching header of 10 minutes on all resources. Google will throw a “Leverage browser caching” error for this. You can override this from the CDN. On CloudFlare, I did this by creating a Page Rule (in addition to the general caching option) that sets the Cache level on everything to a minimum of 8 days (Google’s recommendation). I am not using the Rocket Loader option.
- The CDN will automatically Gzip elements, such as SVG’s (even though they’re served from GitHub)
Setting up the CDN will by far increase your PageSpeed results, but it may take up to 24 hours for your CDN setting changes to propogate - you won’t see them reflected in Google’s results immediately.
LOCALLY SERVE GOOGLE ANALYTICS
TYPEKIT WEB FONTS - AN UNRESOLVED DILEMMA
I was also able to utilize local storage using the TypeKit Cache utility (which also helps resolve Flash of Unstyled Text!).
In the future, I may look into using Google Fonts instead to see if I get better results.
Overall, I don’t think it’s necessary to follow Google’s PageSpeed rules verbatim or even score a passing result. I did find it fun to try to score as high as possible while optimizing my site for these (mostly) valid performance criteria.
If you have feedback or additional tips, be sure to send me a message and let me know!