Black and white illustration of a mentalist on a red background
Part of the HTML Markup Reading List

Developers continually strive to improve web performance, from browsers predictively preloading pages before search terms are completed to coders prioritizing “above the fold” page content. HTML has gone some way towards aiding this process: in the previous article I talked about using rel="next" and rel="previous" to provide page clues to the browser, which can use them to surreptitiously load pages behind the scenes before any user action.

More recently the W3C has added several new features to link as part of the Resource Hints specification that enable more intelligent site content preloading, potentially improving page load times on sites that use them intelligently.

The One Who Knocks

DNS lookup - the process of finding a domain name on the web and translating it to an IP address - can take tens to hundreds of milliseconds. If a user is on your site, their browser already knows its location… but if you’re loading resources from other sites onto the page, the browser must spend time resolving the DNS information of each as it encounters them in the HTML. You can preempt this process by placing a dns-prefetch for external sites in the <head> of your page.

A dns-prefetch example

One common external resource is a Google Analytics script, used to track visitor behaviour on your site. The call to the script is usually placed at the very end of your page: 

<script>
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
  (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
  m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
  })(window,document,'script','http://google-analytics.com/analytics.js','ga');
  ga('create', 'UA-9896842-2', 'auto');
  ga('send', 'pageview');
</script>

We can see that the script calls on http://google-analytics.com/. Rather than trying to resolve that domain name the moment the script is encountered, we can give the browser a hint that the URL will be used, and that it should check that it knows how to reach the site while the rest of your page is being rendered. In the <head> of your document, add: 

<link rel="dns-prefetch" href="//google-analytics.com/">

This potentially speeds up the page load time fractionally for each URL specified in a dns-prefetch, since the browser already “knows” where it is going to go to fetch the resource by the time the parser reaches it.

Opening The Door

preconnect takes this one step further. It does everything that dns-prefetch does, and adds a few further Internet communication negotiations; if dns-prefetch “knocks” to check the location of a site, preconnect opens the door.

A preconnect example

Articles on this site occasionally use resources stored on Amazon S3 servers, called when a page integrates a CodePen demo. To speed up fetching those files, a preconnect is added to the <head>: 

<link rel="preconnect" href="//s3-us-west-2.amazonaws.com/s.cdpn.io/4273/">

Note that I am not specifying a specific file for preconnect, but a location where resources that might be used on the page will be found.

Playing Fetch

One step further is true prefetch, intended to load a resource that is likely to be used in the next user navigation. This would typically be a page that the user is likely to go to after the one they are looking at right now.

A prefetch example

prefetch is most similar to rel="previous" and next, and will most commonly be used the same way. In this case of this article, a likely target for the user is the previous related page: 

<link rel="prefetch" href="/190/Using-link-rel-to-preload-web-content-and-aid-accessibility">

It may be tempting to add every possible page as a prefetch. Please be a good web citizen, and avoid doing this: the browser is likely to ignore you - or worse, exhibit poor performance - if you flood it with too many prefetch requests. Include only those pages that are most likely to be navigated to by the user from a particular page.

Load Without Locking

You can also initiate an early, high-priority, non-render-blocking fetch of a resource that’s used on the current page with the preload keyword.

A preload example

A good use-case of preload is web fonts: traditionally, fonts are loaded only when they are encountered in the CSS, which often leads to the dreaded “Flash of Unstyled Content” as the page renders using default typefaces first, then repaints the page using the web font when it loads in. To avoid this, we can specify to load the font before we hit the CSS. In the case of this site, that would be the Libertad font used to typeset body text: 
<link rel="preload" href="libertad.woff2" as="font">

Note the optional as attribute, which guides the browser to what kind of resource is being loaded.

Rendering Out

The final possibility is to prompt the browser to both fetch and completely render a page behind the scenes, making it available the moment a user clicks on the associated link. Obviously, this should be very rarely used; the most likely application will be on a landing page, where a button launches an fullscreen immersive web experience.

A Prerender Example

One obvious application on this site are demos, such as the one for my HTML5 Page Background video. On the article page, I could add: 

<link rel="prerender" href="/samples/polina.html">

…which would preload and prerender the demo as the user reads the article.

This kind of behaviour has traditionally been achieved by using JavaScript preloaders, and complex sites will likely still require JS code; but for simpler applications, prerender may be very effective.

Resource Hinting as an Investment

It is very important to understand that each of these are hints to the browser, not absolute directives. A browser may or may not follow Resource Hints based upon network bandwidth, memory usage, vendor support, and other factors. As such, they should be considered an investment, rather than a guarantee of performance enhancement, and certainly not a “cure all” for site issues or poor load page load times.

With that in mind, there are several considerations that can improve prefetching, prerendering, and preconnecting behaviour:

  • Effective resource hints rely on paying close attention to page metrics. There’s nothing wrong with guessing where users might go after visiting a page on your site, but hoping is very different from actual data. If you’re launching a new or redesigned site, guesses are fine; but after a week or so of gathering data, site analytics should be used to either: (a) shape user activity by modifying the design of the site to guide visitors where you want them (and where your resource hints are directed), or (b) change the hints to accurately reflect user behaviour.
  • Not just for browsers. Together with <link rel="next" …> and rel="previous", resource hints provide search engines with a further opportunities to rank and link content. For example, next and previous can be used by Google to help determine site organizational structure, and prioritize results for the first page in a related series.

Conclusion

As part of a constant, strategic focus on site performance, resource hints can be a very effective technique to accelerate page delivery times; for optimum results, they should be combined with a thorough, professional, content strategy to tell you what information should be where on the site.

Enjoy this piece? I invite you to follow me at twitter.com/dudleystorey to learn more.