Today we are going to explore current resource hints and directives which can be another great way to boost the performance on your website or web application. You might have heard of preload, prefetch, and preconnect, but we want to dive deeper into the differences between them how how you can benefit from them. Some of the advantages of these is that they allow web developers to optimize delivery of resources, reduce round trips, and fetch resources to deliver content faster while a user is browsing a page.

Preload

Preload is a new web standard that offers more control on how particular resources are fetched for current navigation. This is the updated version of subresource prefetching which was deprecated in January 2016. This directive can be defined within a <link> element for example as <link rel="preload">. Generally it is best to preload your most important resources such as images, CSS, JavaScript, and font files. This is not to be confused with browser preloading in which only resources declared in HTML are preloaded. The preload directive actually overcomes this limitation and allows resources which are initiated via CSS and JavaScript to be preloaded and define when each resource should be applied.

Preload is different from prefetch in that it focuses on current navigation and fetches resources with high-priority. Prefetch focuses on fetching resources for the next navigation which are low priority. It is also important to note that preload does not block the window’s onload event.

Benefits of Preload

Some of the benefits of the preload directive include:

Allows the browser to set resource priority therefore allowing web developers to optimize the delivery of certain resources.

Gives the browser the ability to determine the resource type therefore it can tell if the same resource can be reused in the future.

The browser can determine if the request is compliant with the content security policy by referencing what is defined in the as attribute.

The browser can send the appropriate accept headers based on resource type. (such as image/webp)

Examples

Here is a very basic example of preloading an image.

<link rel="preload" href="image.png">

Here is an example of preloading fonts. Note: If you are preloading links with CORS enabled resources you must also include the crossorigin attribute.

Prefetch is a low priority resource hint that allows the browser to fetch resources in the background (idle time) that might be needed later, and store them in the browser’s cache. Once a page has finished loading it begins downloading additional resources and if a user then clicks on a prefetched link, it will load the content instantly. There are three different types of prefetching, link, DNS, and prerendering which we will go into more below.

1. Link Prefetching

As mentioned above, link prefetching allows the browser to fetch resources, store them in cache, assuming that the user will request them. The browser looks for prefetch in the HTML <link> or the HTTP header Link such as:

HTML: <link rel="prefetch" href="/uploads/images/pic.png">

HTTP Header: Link: </uploads/images/pic.png>; rel=prefetch

Link prefetch is supported by most modern browsers with the exception of Safari, IOS Safari, and Opera Mini. Chrome and Firefox will also show prefetched resources in the network panel if you are trying to test.

2. DNS Prefetching

DNS prefetching allows the browser to perform DNS lookups on a page in the background while the user is browsing. This minimizes latency as the DNS lookup has already taken place once the user clicks on a link. DNS prefetching can be added to a specific url by adding the rel="dns-prefetch" tag to the link attribute. We suggest using this on things such as Google fonts, Google Analytics, and your CDN. It is also useful for resources behind a redirect. See example below.

It is also important to note that Google Chrome does something similar already when you type things into your address bar, such as DNS preresolve and TCP preconnect. Which is pretty cool! You can see your list by going to chrome://dns/.

You can also take advantage of the Pagespeed filter insert_dns_prefetch which puts <link rel="dns-prefetch"> tags in the page header automatically for all domains.

Prerendering is very similar to prefetching in that it gathers resources that the user may navigate to next. The difference is that prerendering actually renders the entire page in the background, all the assets of a document. Below is an example.

You want to be more careful with prerendering as it is resource heavy and can cause bandwidth waste, especially on mobile devices. It is also important to note that you can’t test this with Chrome DevTools, instead you can see if a page is being prerendered at chrome://net-internals/#prerender. You can also test it yourself at prerender-test.appspot.com.

Prerender is supported by some browsers with the exception of Mozilla Firefox, Safari, IOS Safari, Opera Mini, and Android Browser.

Web statistics might be inflated even though Google says it suppresses the tag. See an example from this blog post about web analytics tags possibly firing and registering two sessions for one click.

Users may be exposed to more security risks by downloading more pages, or from un-requested sites (additionally compounded as drive-by downloads become more advanced and diverse).

Users may violate acceptable-use policies of their network or organisation if prefetching accesses unauthorized content.

Make sure to check out our in-depth post on using prefetching resource hints.

Preconnect

The final resource hint we want to talk about is preconnect. Preconnect allows the browser to setup early connections before an HTTP request is actually sentto the server. This includes DNS lookups, TLS negotiations, TCP handshakes. This in turn eliminates roundtrip latency and saves time for users.

A preconnect can be added directly to a link tag as an attribute in the HTML. It can also be delivered through the Link HTTP header or can be invoked by Javascript based on user activity. Here is an example of enabling preconnect for a CDN URL.

Below is an example of using preconnect with Google Fonts. By adding a preconnect hint for fonts.gstatic.com, it begins the request in parallel with the CSS request, allowing the font request to be sent immediately. In this particular scenario, preconnect removed three RTTs from the critical path and eliminated over half of second of latency. See more on lya Grigorik’s detailed post on eliminating RTTS with preconnect.

src: Ilya Grigorik

Using preconnect in an efficient and thought out manner will not only help optimize your website but will also keep you from under-utilizing resources. Preconnect is supported by some modern browsers with the exception of Internet Explorer, Safari, IOS Safari, and Opera Mini.

Make sure to also check out our in-depth post on using preconnect resource hints.

Summary

Hopefully now you understand a little better what preload, prefetch, and preconnect are and how you can utilize them to speed up delivery of content and assets by using them in a strategic manner. It will be exciting to see the preload directive gain more support over the next couple months and web developers starting to adopt it more.

What are your thoughts on these resource hints? Have you experimented with all of them yet? If so, we would love to hear about it below in the comments.