Link Rel Preload and Site Speed: A Preliminary Guide

A lot of the initiatives in the web development world and the search engine rankings have been around providing a positive user experience. From the many, web performance holds great importance.

And from the myriad of options available for improving site speed, link rel Preload is one of them.

What Is rel="preload" ?

When rel="preload" was introduced, its goal was to provide more granular control to web developers on instructing the browsers as to which resources are critical for a page and that they would be needed very soon when rendering starts to occur.

At the end of the day, the entire purpose of rel="preload" is to prevent important resources from becoming render blocking (as much as possible, or reducing the likelihood), and therefore, improve performance.

How rel="preload" Works

When resources are assigned a rel="preload" (as the name suggests), the browser interprets it as something that will be needed very soon — as mentioned. Consequently, it starts to cache these resources ASAP.

Realize that this instruction is a fetch directive, so it occurs before rendering starts to happen. This provides a huge advantage because when rendering does initiate, the browser already has preloaded the information of when these resources would need to be loaded, versus trying to understand at that time. Because of this behavior, the resources are unlikely to be render blocking (compared to if they hadn’t been assigned rel="preload"), and ultimately, gives an edge towards boosting your site speed.

How To Apply rel="preload"

To apply rel="preload" to a resource, we need the following 2 pieces of information handy, or need to be aware of prior to:

1. The URL/Path to the resource. For example, the URL to the CSS stylesheet.
2. Know what type of resource we want to preload. That is, would it be a CSS stylesheet, a video, a font file, script, etc.

Syntax for rel="preload"

The following piece of code can be considered a syntax for applying rel="preload":

<link rel="preload" href="the-url-of-the-resource" as="type of resource">

Where:
1. the-url-of-the-resource = the path of the resource
2. type of resource = what type it is

Let’s break this down with an example. Say I have a CSS stylesheet file residing at /abc/def.css. In that case, the actual code would look like:

<link rel="preload" href="/abc/def.css" as="style">

To establish the concept further, say I have a JavaScript file located at /this-is-a-js-file.js. In that case, the literal code would be:

<link rel="preload" href="/this-is-a-js-file.js" as="script">

Why It’s Important To Assign ‘As’?

According to MDN Web Docs, assigning the as value has some great benefits. They are:

• It allows the browser to understand what the resource is in the first place more accurately, so it prioritizes its load accordingly.
• It can enable browsers to store its cache for more requests in the future, or fetch it again, if needed.
• Help browsers in applying the more proper & more applicable security for that resource.
• Also help the browsers to set the appropriate accept request header for the said resource.

Here’s the screenshot — straight from MDN Web Docs.

What Types of Resources Can Be Preloaded?

Rather than regurgitating an already presented information, I’d simply guide you to the screenshot below, which is pulled directly from MDN Web Docs. They’ve done an excellent job of laying out the possible assets — that you can preload.

Special Note About Preloading Fonts (Real-World Example To Follow)

A lot of the font files are woff2, and therefore, outside of specifying that it’s a font in the as attribute, we’d need to specify that it’s a type of woff2 as well (or other if applicable).

The second important aspect to note here is that we’d also have to declare the crossorigin attribute. Preloading fonts has its own oddity where without the crossorigin being added to your code, the browser will ignore the command. Further, it will try to fetch it again (or likely twice), entirely defeating the purpose of preloading.

Generally speaking, the value you’d assign to crossorigin would be anonymous — because that’s what the expectation is. At this point, perhaps this is all we should know about crossorigin, as it’s quite a technical concept to grasp — and beyond my full understanding also, at the moment.

To recap, when preloading fonts, outside of what you’d do with a preload command, keep the following in mind:

• Make sure you state what type of font it is with type
• Also make sure that you assign anonymous to the crossorigin attribute (although, simply specifying crossorigin might do the trick).

Live Real-World Example of Preloading Fonts

If all of that sounded confusing, and you’re looking for a live example, check out the source code of this site.

I am preloading two fonts (screenshot below).

For reference, below is the full code for one of the fonts:

<link rel="preload" href="https://feedthecuriosity.com/wp-content/themes/twentytwenty/assets/fonts/inter/Inter-upright-var.woff2" as="font" type="font/woff2" crossorigin="anonymous">

In Closing

In the entire ecosystem of improving site speed, rel="preload" can be quite advantageous if leveraged.

As the world gets hungrier for more speed, it’s imperative to know the technologies and solutions that support such an initiative — with rel="preload" being one of the many.