Using rel=preload to speed up render blocking resources on hluska.ca

Speeding up site performance by eliminating render blocking resources

Filed under: Projects, Web performance, Speeding up hluska.ca

Last post

Last post, I talked about a Siteimp audit that I ran earlier on today. My performance was quite good but I wanted to optimize it a little more. The Siteimp report identified two major problems with my website. I learned that:

Unused CSS is a problem on 100% of my pages.
Render blocking resources are a problem on 100% of my pages.

I have decided to tackle render blocking resources first because I know that unused CSS files could be part of my problem with render blocking resources.

Render blocking resources

First though, it’s important to understand what a problem with render blocking resources means. Last post, I quickly defined critical resources and critical resource paths. I’ll start by going into considerably more detail on both of those.

Critical resources

Critical resources are any resources that you need in order to render your page. Your page will not render until all critical resources have been downloaded and processed.

Critical resource path

The critical resource path refers to everything that a user’s browser has to do before they can start using your web page. Your page will not fully render until the critical resource path is finished.

What does this mean?

The fewer critical resources, pre render tasks and critical resource bytes the better. All of these things contribute to the length of your critical resource path. The shorter your critical resource path, the faster your page renders. The faster your page renders, the faster your users can use it. And the faster they can use your page, the happier they will be with you and your entire website.

Make sense?

Critical resources on hluska.ca

Digging into the Siteimp report and taking a look at the template of my page, I have identified the following critical resources to get my site to function and render properly:

https://cdnjs.cloudflare.com/ajax/libs/uikit/3.4.0/css/uikit.min.css
https://cdnjs.cloudflare.com/ajax/libs/font-awesome/5.14.0/css/all.min.css
https://cdnjs.cloudflare.com/ajax/libs/uikit/3.4.0/js/uikit.min.js

These three files make up UI Kit and Font Awesome. They are relatively large and users have to download these entire files in order to use my site. They’ll be cached in their browsers between page loads, but I’m most interested in making sure that someone’s first load on my website is extremely fast.

I download the first two files in the head of my website and the last one in the footer. Since I download the UI Kit javascript library in the footer, a user’s browser won’t even start working on it until it’s processed all the way to the bottom. My .html documents are small but that’s still an unacceptable delay.

rel=preload

One good way to shorten your critical resource path is to tell a user’s browser to download critical resources as soon as possible. If you set rel=preload in a resource request path (I’ll show you in a second), you tell a user’s browser to fetch it sooner than their browser would normally find it. This can shave a significant amount of time from a user’s critical resource path.

Here is the old header from my website (Everything in {{ }} is a Hugo command):

<head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>{{ $title }}</title>
    <meta name="description" content="{{ .Description }}">
    <link rel="canonical" href="{{ .Permalink }}" />
    <link rel="icon" href="/images/favicon.ico">
    <!-- CSS -->
    <link rel="stylesheet" type="text/css" href="/css/style.css">
    <link rel="stylesheet" type="text/css" href="https://cdnjs.cloudflare.com/ajax/libs/uikit/3.4.0/css/uikit.min.css">
    <link href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/5.14.0/css/all.min.css" rel="stylesheet">
    <!-- /CSS -->
    <meta name="robots" content="index,follow" />
</head>

Here is the new header from my website, with the UI Kit javascript library preloaded and with the other CSS files loaded slightly earlier than before (again, everything in {{ }} is a hugo command):

<head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <link rel="preload" href="https://cdnjs.cloudflare.com/ajax/libs/uikit/3.4.0/js/uikit.min.js" as="script">
    <!-- CSS -->
    <link rel="stylesheet" type="text/css" href="/css/style.css">
    <link rel="stylesheet" type="text/css" href="https://cdnjs.cloudflare.com/ajax/libs/uikit/3.4.0/css/uikit.min.css">
    <link href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/5.14.0/css/all.min.css" rel="stylesheet">
    <!-- /CSS -->
    <meta name="description" content="{{ .Description }}">
    <link rel="canonical" href="{{ .Permalink }}" />
    <link rel="icon" href="/images/favicon.ico">
    <meta name="robots" content="index,follow" />
</head>

Moving my CSS up that high is a very tiny, picky optimization but it may save a millisecond or two. My goal is to get my scores as high as possible so every millisecond helps me here!

This line of code tells a user’s browser to start downloading the UI Kit javascript file really fast. It warns the browser that it’s going to be included in the footer and it’s important (mobile menus won’t work properly without it).

<link rel="preload" href="https://cdnjs.cloudflare.com/ajax/libs/uikit/3.4.0/js/uikit.min.js" as="script">

Wrapping it up

I made one major and one very small change to the head template that I use on every page on this website. I warned a user’s browser that they were going to need a UI Kit javascript library later on and asked them to fetch it earlier than they’d usually find it. And I moved the rest of my CSS files up.

I’m going to look at all the CSS I download to build my pages and decide whether or not I want to keep using it. And if so, how am I going to load it?

The series

Improving hluska.ca’s performance with a Siteimp audit - last post
Eliminating render blocking resources part 1 - rel preload - this post
Thinking through css on hluska.ca - next post
Checking in on those changes
Investigating Font Awesome on my contact page
Minifying my site with Hugo on DigitalOcean App Platform
Writing a Hugo shortcode to optimize my images with UI Kit
Final results from my site improvement program

You just finished reading Using rel=preload to speed up render blocking resources on hluska.ca.

It was filed under: Projects, Web performance, Speeding up hluska.ca

You can see all of Greg's articles, send him a message with any feedback or follow him on Twitter.

↑
Top

Greg Hluska