Link rel=preload: Prioritize Resources for Better Site Speed

Last updated on Dec 23rd, 2022 | 11 min

TL;DR: Link rel=preload is a powerful directive site owners can implement to the head of their site’s HTML to control the earlier fetching of critical resources discovered late by browsers in the page render process. Preloading improves site responsiveness metrics (FID, Interaction to Next Paint) and Core Web Vitals (LCP, CLS), contributing to faster load times. Rel preload should be used sparingly after careful request chain analysis for best results.


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.

Preload adoption by rank

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!

See how much faster your website can be with NitroPack


Resource Prioritization Explained

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.

Browser resource priority

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. 

Optimized rendering vs unoptimized

Optimize critical resources on autopilot! See your site with NitroPack.

What is link rel=preload?

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.

 

What browsers support link rel=preload?

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.”
 

Is link rel=preload necessary?

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 requests 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.


Is link rel=preload render-blocking?

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 example of overusing preload

(Asana home page example) The green line in the request waterfall chart shows when the page starts rendering. Source: article by DebugBear
 

Link rel=”preload” vs. rel=”prefetch”

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.


What web page elements can I preload?

As mentioned before, link rel preload is suitable for resources typically discovered late by the browser.

Resources you can preload include:

  • Sound and music files
  • Video (MP4, MP3, WebM)
  • Audio WebVTT tracks
  • JavaScript files
  • CSS style sheets
  • Web fonts (TTF, EOT, WOFF, WOFF2)
  • Images (AVIF, WebP, JPG, and JPEG, or PNG)
  • XHR and fetch API requests
  • Web workers
  • Multimedia embed and object requests

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:

Value of as attribute

Important:
Failing to specify a valid “as” attribute causes the browser to misidentify the asset it’s fetching and incorrectly prioritize it.
The “href” attribute specifies the resource that will be preloaded (aka links to the resource itself).


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. 
 

How to link rel=preload images

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:

HTML preload image

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.

HTML preload responsive image

Optimize all your images for fast load times and responsiveness on autopilot. See your site with NitroPack.


How to link rel=preload web fonts

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:

Preload font HTML code

 

Important:
Fonts preloaded without the crossorigin attribute will be fetched twice!
Limit the number of fonts you preload to those essential to the initial page load (i.e. fonts found above the fold and only the styles that are actually used)


How to link rel=preload JavaScript files

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">


When should I use link rel preload?

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.


How to check which resources to preload?

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

Network Tab Chrom DevTools

Step 3: Right-click on the “Name” section to switch the “Priority” column on

Priority Column Chrome DevTools

Step 4: Explore how resources were loaded and what priority they were assigned to pinpoint possible assets for preloading

Priority Inspect Chrome DevTools

Additionally, your Lighthouse report features an “Opportunities” section that flags late-discovered assets in your critical request chain as preload candidates:

Lighthouse Priority Opportunities

 

How do I know if preload is working properly?

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:

Preload Example Before/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.


How to not misuse link rel=preload

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.

  • Unwanted interference with the browser’s usual behavior
  • Excessive usage of resources (i.e. using up bandwidth faster than usual)
  • Harmful impact on the critical rendering path stopping browsers from doing the right thing


Mistake #1: Preloading too many resources

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.
 

Mistake #2: Preloading unused content

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).

Unused preload warning

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.
 

Mistake #3: Preloading non-essential resources

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.
 

Mistake #4: Preloading non-existent content

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.

 

Which Core Web Vital metrics does rel=preload improve?

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:

  • Largest Contentful Paint (LCP): large above-the-fold resources (like hero images and big chunks of text) are great LCP candidates. Delivering them faster can help you improve the Core Web Vitals metric websites struggle with the most.
  • Cumulative Layout Shift (CLS): preloading web fonts shows significant improvement in font-related layout shifts such as Flash of Unstyled Text (FOUT) and Flash of Invisible Text (FOIT).
  • First Input Delay (FID) and Interaction to Next Paint (INP): preloading JavaScript that powers important interactions helps you reach better responsiveness levels in line with the user's intent.


Link rel=preload benefits in popular websites

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:

  1. Shopify with a 50% (1.2 seconds) improvement in Time to Next Paint on Chrome desktop when preloading web fonts, which removed Flash of Invisible Text completely;
  2. Flipkart cut a substantial amount of main thread idle by preloading their key bundles;
  3. Notion with a 10% improvement in page render metrics by preloading 9 basic API calls;
  4. Financial Times cut 1 second off the time it took to display the masthead image by using a link preload header.

 

Shopify Before/After preloading

Shopify with preload (left) and without preload (right). Source: Article by Addy Osmani

Join the top 31% of high-speed websites! See the impact of NitroPack first-hand.


Summary

Link rel=preload is an effective resource prioritization technique for speeding up your site and offering 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 Raykova
Content Manager

Lora is a full-time content strategist and copywriter with a knack for uncovering stories that resonate with readers. Her curiosity toward all things tech helps her turn your "Huh?" into "Aha!"