Link rel=preload: Prioritize Resources for Better Site Speed
Last updated on Mar 13th, 2024 | 11 min
Special Black Friday Offer 
Get NitroPack with up to 37% OFF
Get NitroPack with up to 37% OFF
Once you start with NitroPack, you can freely choose your integration platform.
Everything you need to know about
NitroPack features and compatibilities.
Whether you run a blog or
an agency, we have a
partnership opportunity for you!
The place to learn how to
improve your web performance,
how to get the most out of
NitroPack, and what is coming
next to our product.
In 2016, w3c, along with Yoav Weiss, released a new web standard for Chrome called link rel="preload" opening new paths to faster load times.
Six years later, preloading is the #1 resource prioritization technique adopted by top-ranking sites for improving load speed and user experience.
Bar chart showing the adoption of rel="preload" segmented by CrUX rank. Source: Web Almanac 2021
The growing popularity of link rel=preload proves how effective it can be. Which also makes it prone to misuse.
Due to its flexibility, preloading important resources requires deeper knowledge if you want to do more good than harm.
In this article, you’ll learn:
Let’s dive straight in!
Manual resource prioritization is your way of taking the guesswork modern browsers do out of the page loading process.
However, before you start influencing how and when resources are loaded, we should cover some basics.
By default, browsers will try to figure out which assets to request and in what order. When a browser downloads a resource, it is always assigned a priority: highest, high, medium, low, or lowest.
Priorities depend on the resource type (e.g., text, image, stylesheet, script, video) and the placement of the resource reference in the document.
When choosing which assets to preload you have to be mindful of render-blocking resources and not stop browsers from downloading them first. Otherwise, you might end up showing a blank page instead of loading it faster.
Simply put, link rel=preload is a command to tell browsers you’d like them to fetch an important resource sooner than they would normally discover it.
Unlike other resource prioritization techniques like prefetch and preconnect, preloading isn’t simply a hint but a declarative. This means browsers are forced to fetch the resource you know is crucial to the page experience.
You can preload resources by adding a link tag with rel="preload" to the head of your HTML document:
<link rel="preload" as="script" href="critical.js">
Don’t worry; we’ll go through the specifics in a bit.
Preloading is supported by all major browsers enabling site owners and developers to offer faster load times and user experience limit-free.
For a detailed breakdown of supported browser versions, see this table by “Can I use.”
Preloading crucial resources gives you granular control to define custom loading logic. Whether your site needs it depends on the results of your audits.
For high-quality key request evaluation, we recommend exploring manual web page speed tests and field-lab data collected in-house.
Hyper-jump to: How to check which resources to preload.
The preload tag can interfere with the proper rendering of the page when used for non-essential files in large quantities. In this case, instead of focusing on important render-blocking resources, the browser is busy with a lot of low-priority files.
For example, the Asana homepage features 26 preload tags for JavaScript files of low importance. That results in substantial delays in the page’s rendering, which hurts the user experience.
(Asana home page example) The green line in the request waterfall chart shows when the page starts rendering. Source: article by DebugBear
When preloading first became available many users were confused about its benefits compared to the already existing prefetch directive.
Prefetch focuses on a resource that will most likely become essential for future navigations (meaning after the current page). Preload, on the other hand, deals with a resource for the current navigation.
As mentioned before, link rel preload is suitable for resources typically discovered late by the browser.
Resources you can preload include:
The preload directive features a powerful “as” value. It is essential to tell browsers what priority to give the resource you’re preloading without delaying more important files or falling behind less important ones.
Here’s a handy list of “as” values you can specify:
Yoav Weiss (member of the Google Chrome developers relations team) also notes:
“...preload does not block the window’s onload event unless the resource is also requested by a resource that blocks that event.”
Let’s review the most common resources site owners and developers choose to preload.
There’s always at least one page on your site with a large image in the viewport welcoming site visitors right at the start. Such images are perfect candidates for preloading.
Remember, preload resources by adding a link tag with rel="preload" to the head of your HTML document. Like so:
The result is your image loads sooner and improves one of the most challenging Core Web Vitals metric – LCP.
However, to preload responsive images, you need to use imagesrcset and imagesizes attributes to help browsers select the appropriate image to download depending on the screen size.
Fonts defined with @font-face rules in CSS files aren’t fetched until browsers download and parse the CSS files. That’s why web fonts are the second most popular asset top-ranking websites choose to preload.
Here’s an example snippet:
To improve responsiveness metrics like Time to Interactive, we recommend you split hefty JavaScript bundles and only preload critical chunks.
That way, browsers can separate fetching from execution and discover that particular resource earlier before downloading the whole JS bundle.
It would go something like this:
<link rel="preload" as="script" href="late_discovered.js">
This is a case of “it depends.”
The general rule is to only preload late-discovered assets that you know are essential for the first interactions when a visitor lands on a page.
As we mentioned earlier, the best way to determine which resources to preload is to audit how your web pages load.
Luckily, you can identify resources to preload using the Request Waterfall Charts in Chrome DevTools.
Step 1: Visit the web page most of your visitors land on and “Inspect” it
Step 2: Navigate to the “Network” tab and refresh the page to generate the Waterfall chart
Step 3: Right-click on the “Name” section to switch the “Priority” column on
Step 4: Explore how resources were loaded and what priority they were assigned to pinpoint possible assets for preloading
Additionally, your Lighthouse report features an “Opportunities” section that flags late-discovered assets in your critical request chain as preload candidates:
After you identify your candidates for preloading, you can start testing if your link rel=preload is doing its job.
Do so using the same Request Waterfall Chart in DevTools. If you correctly chose the asset for preloading and put in valid attributes, as shown earlier, you should see an improvement in page load times.
Here’s an example Before and After:
(Before preload): the font file “Pacifico-Bold.woff2” is downloaded only after the stylesheet “main.css”. (After preloading the font file): the download of the font happens in parallel with the stylesheet.
Given the impressive results a few proper preload tags can show, it’s easy to get carried away.
But because of the nature of preloading a series of performance issues may arise.
There isn’t an exact number you should be aiming for but be very mindful when choosing which resources to preload. Remember, you should target late-discovered assets that are critical for first-time interactions with the web page.
More often than not, we would find a link rel=preload in the common header even though the preloaded resource is located on one web page only (e.g. a landing page).
Warning message for preloading unused content
This might just a simple mistake or insufficient coding. In that case, splitting general bundles into smaller targeted ones for specific templates is a much better approach.
Preloading just any resource isn’t going to get you the speed boost you desire. Assets that aren’t critical for the rendering and interactivity of the above-the-fold experience are better left with a lower priority.
Instead, aim to find the elements that browsers discover later than you’d like.
This happens rarely, but when it does the result is a 404 page. This is a no-go when preloading, and you should always double-check if the resource is in fact valid.
By now, we’ve seen undeniable proof of the speed optimization power of preloading. It boosts load times, improves performance metrics and responsiveness, and helps you make a great first impression.
Here are the metrics that see the most improvement after correct preloading:
In 2017, the Chrome Data Saver (now sunsetted) team applied preloading on scripts and CSS stylesheets and saw an average of 12% time to First Contentful Paint improvements for the affected pages.
Other success stories of improved loading metrics with link rel=preload include:
Shopify with preload (left) and without preload (right). Source: Article by Addy Osmani
Link rel=preload is an effective resource prioritization technique for speeding up your site and offering a better user experience at first contact.
Use this directive sparingly and only for late-discovered resources that are critical for the above-the-fold experience. Make sure to first analyze how browsers download and parse your assets with the help of Chrome DevTools and Lighthouse.
Implementing rel=”preload” properly will improve site responsiveness and performance metrics that are vital for the success of your online business.
Lora has spent the last 8 years developing content strategies that drive better user experiences for SaaS companies in the CEE region. In collaboration with WordPress subject-matter experts and the 2024 Web Almanac, she helps site owners close the gap between web performance optimization and real-life business results.
