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
preconnect, but we want to dive deeper into the differences between them 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 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 is different from
prefetch in that it focuses on fetching a resource for the current navigation.
prefetch focuses on fetching a resource for the next navigation. It is also important to note that
preload does not block the window's
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
- The browser can send the appropriate
Acceptheader based on resource type (e.g.
Here is a very basic example of preloading an image.
<link rel="preload" href="image.png">
Here is an example of preloading fonts. If you are preloading links with CORS enabled resources you must also include the
<link rel="preload" href="https://example.com/fonts/font.woff" as="font" crossorigin>
<!-- Via markup -->
<link rel="preload" href="/css/mystyles.css" as="style">
var res = document.createElement("link");
res.rel = "preload";
res.as = "style";
res.href = "css/mystyles.css";
Scott Jehl, from the Filament Group, also has an interesting workaround to get async loaded styles using markup. Which means it is non-render blocking!
preload browser support
Read our full in-depth article on the
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
<link> HTML element or the
Link HTTP header such as:
<link rel="prefetch" href="/uploads/images/pic.png">
- HTTP header:
Link: </uploads/images/pic.png>; rel=prefetch
This technique has the potential to speed up many interactive sites, but won't work everywhere. For some sites, it's just too difficult to guess what the user might do next. For others, the data might get stale if it's fetched too soon. It's also important to be careful not to prefetch files too soon, or you can slow down the page the user is already looking at.
- Google Developers
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.
DNS requests are very small in terms of bandwidth, but latency can be quite high, especially on mobile networks. By speculatively prefetching DNS results, latency can be reduced significantly at certain times, such as when the user clicks the link. In some cases, latency can be reduced by a second.
- Mozilla Developer Network
It is also useful for resources behind a redirect. See example below.
<!-- Prefetch DNS for external assets -->
<link rel="dns-prefetch" href="//fonts.googleapis.com">
<link rel="dns-prefetch" href="//www.google-analytics.com">
<link rel="dns-prefetch" href="//cdn.domain.com">
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
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.
DNS prefetch is also supported by most modern browsers with the exception of Opera Mini.
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.
<link rel="prerender" href="https://www.keycdn.com">
The prerender hint can be used by the application to indicate the next likely HTML navigation target: the user agent will fetch and process the specified resource as an HTML response. To fetch other content-types with appropriate request headers, or if HTML preprocessing is not desired, the application can use the prefetch hint.
Source: Chrome Prerendering
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.
Besides extra resources there are some additional cons to using prefetching, such as criticisms regarding the privacy.
- Web statistics might be inflated even though Google says it suppresses the tag.
- Users may be exposed to more security risks by downloading more pages, or from unrequested 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.
The final resource hint we want to talk about is
preconnect directive allows the browser to setup early connections before an HTTP request is actually sent to the server. This includes DNS lookups, TLS negotiations, TCP handshakes. This in turn eliminates roundtrip latency and saves time for users.
Preconnect is an important tool in your optimization toolbox... it can eliminate many costly roundtrips from your request path - in some cases reducing the request latency by hundreds and even thousands of milliseconds.
- Ilya Grigorik
preconnect can be added directly to a link tag as an attribute in the HTML. It can also be delivered through the
preconnect for a CDN URL.
<link href="https://cdn.domain.com" rel="preconnect" crossorigin>
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.
Source: Ilya Grigorik
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.
Hopefully now you understand a little better what
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.