Site optimizations
Over the last week I’ve done my best to boost the performance of this website,
I figured I’d write a summary on the techniques utilized.
Baseline
To measure any performance improvements, we must first establish a baseline.
A few details about what we use to publish this website.
The website is build on Jekyll, it utilizes the Chalk theme from Nielsen Ramon.
This theme features a lot of optimizations already, resulting in my job being easier. It is hosted on Gitlab, with a heavily modified docker image, while being served and supported through Cloudflare. These platforms were selected to create an easily maintainable, autonomous and low cost website with maximum performance.
To measure and improve performance, we’ll will use two tools provided by Google, Lighthouse and Page Speed.
Below is the baseline Lighthouse report. The Pagespeed results are already satisfactory at a 96/100 for desktop and 94/100 for mobile, but both of these tools make some good suggestions to improve performance.
Site optimization
Lighthouse made the following notable recommendations:
- Eliminate render-blocking resources.
- Ensure text remains visible during webfont load.
- Preconnect to required origins.
- Background and Foreground colors do not have a sufficient contrast ratio.
Most of the other recommendations are limited by third-party modules or are related to the ‘PWA’ score, which is mostly irrelevant for the content we’re trying to serve on VGrol.
Pagespeed merely mentioned the leveraging of optimal cache durations and while I have adjusted these to the recommended duration of eight days, the Cloudflare module that obfuscates email addresses listed on this website, seems to have an immutable cache duration of two days, which results in google still complaining that we’re not leveraging cache correctly.
While I have reached out to Cloudflare to correct the issue for this particular module, it remains an issue for all content not directly delivered by the source. Cloudflare stated that they are working on a solution. So if we were to implement Google Analytics or Google Tag Manager it would result in a similar issue.
Eliminate render-blocking resources
This one was quite the hurdle. The initial solution was to simply utilize:
@inlineWhere the .css files were invoked in the Header.
However this caused a singular problem with two undesirable symptoms.
The Inline value breaks Cloudflare minification, something we’ve been relying on for optimal page delivery. This results in all of the .JS and .CSS files referenced by files now provided with the ‘@inline’ value, being registered as inefficiencies by Lighthouse.
To fix multiple CSS files being loaded indirectly at once, I pointed the ‘@inline’ file from the fonts.scss and theme.scss files to fonts-theme.scss, which uses ‘@import’ to reference both of the previously mentioned files.
Alright, that is the first problem sorted, onto the next.
My plan was to provide the following flag to Jekyll.
assets:
compression: true
This however, turned up the following error:
Liquid Exception: no implicit conversion of Symbol into Integer in /_layouts/post.htmlThis took me many hours to troubleshoot, but it turned out to be caused by Jekyll-assets. This module doesn’t like to play with the ES6 structured liquid tags provided by Chalk. On the brightside, it turns out that the 4.0 release of Sprockets has a module that automatically converts ES6 into ES5. Now that we know this, we can simply specify the version in the Gemfile like so.
gem "sprockets", "4.0.0.beta8"
This results in compression now working and minifying all the provided CSS and JS locally, thus resolving this bullet point.
Ensure text remains visible
Quite an easy fix, just set the following value for each font referenced in the font.scss file. In my case I opted for the ‘Auto’ value on the secondary fonts with the ‘fallback’ value for the primary font.
font-display: 'value'Preconnect to required origins
In the case of this website, it merely needed a preload to the cloudflare domain. I had some problems with the recommended tag ‘preload’ and had to substitute it with ‘preconnect’ instead.
<link rel="preconnect" href="https://discovery.amp.cloudflare.com">Background and Foreground colors
For some reason Google really didn’t like the colours of the article dates. A quick fix was making the colour a tad brigther in the CSS file, I simply shifted the palette around.
$gray-darker: lighten($gray-darkest, 15 -> 24 );
$gray-dark: lighten($gray-darkest, 30 -> 42 ); # This was the actual value that needed modification.
$gray: lighten($gray-darkest, 45 -> 52 );
$gray-light: lighten($gray-darkest, 60 -> 64);
$gray-lighter: lighten($gray-darkest, 75 -> 74);
$gray-lightest: lighten($gray-darkest, 85 -> 88);SEO optimization
Now that we’ve covered Site performance, lets tell google how to find us. First to utilize the Jekyll-seo-tag module, we need to append a tag to the header file.
{% SEO %}Perfect.
To request a new cache and tell google where the Sitemap is, I registered the domain with Google URL Inspector. This required me to provide proof of ownership, which was quickly provided by inserting a meta tag to the header file.
<meta name="google-site-verification" content="Unique Google ID here"/>
Now I could tell google where my site map is, which is provided by ‘Jekyll-sitemap’ and then automatically becomes available at ‘domain’/sitemap.xml. While I was there I also told google to scrape the domain for updated information.
Conclusion
Now what has all of this brought us? The new Pagespeed result is 97/100 for mobile, and 99/100 for desktop. Though it seems to want to average to 94/100 for mobile and 97/100 for desktop, probably due to CDN fluctuations. The Lighthouse results are as followed. 
It appears that the only thing preventing ‘Best practices’ from reaching 100 is another Cloudflare module.
All in all, this was a good learning exercise and has been an entertaining method of avoiding AMP all together.
Hopefully this has given a little insight at how this website is optimized.