Faster Loading Times with Prefetch, Preload and Prerender

This article gives you an overview of possible techniques you can use for prefetch, preload and prerender. The general process is always identical, and very simple. With the href attribute, the HTML element defines to which URL or resource the preloading should refer. The rel attribute then indicates the type of preloading. This article doesn’t go into detail on which browsers support this feature, as this information becomes outdated very quickly, and this isn’t necessary according to the progressive enhancement approach.

DNS Prefetch

<link rel="dns-prefetch" href="//en.ryte.com">

With this line of code, which should be placed in the area of the website, the browser is instructed to resolve the domain name. The "Domain Name System" has the task of connecting domains to their respective IP addresses.

When you type a URL into the address bar of a browser, the browser doesn’t know what to do with the domain or the host alone. It needs the IP address of the server. This DNS resolution takes time; usually between 20 and 250 milliseconds. With the -element, you can cut this process short by carrying out the translation of a domain or URL before the user clicks.

Preconnect

<link rel="preconnect" href="//en.ryte.com">

Preconnect is very similar to the DNS prefetch feature. The only difference is that it goes a step further and carries out a TCP (Transmission Control Protocol) and TLS (Transport Layer Security) handshake. In addition to collecting the DNS information, these are important processes that normally take a few milliseconds.

If you want to prefetch domains with an SSL certificate (e.g. https://de.ryte.com it makes sense to use the element. Or, both elements can be combined:

<link rel="dns-prefetch" href="//en.ryte.com">
<link rel="preconnect" href="//en.ryte.com">

Prefetch

<link rel="prefetch" href="//en.ryte.com/image.jpg">

'Prefetch' sounds almost identical with “DNS Prefetch described above”, but it’s very important not to confuse them with each other. Prefetch should mainly be used to preload static resources like images, CSS– and Javascript files. The entire file is downloaded and saved in the browser cache. Prefetching HTML documents is also possible, but later in the article we'll show you some more effective methods for this.

However, bear in mind that you can't rely on a resource being downloaded. Browsers use their capacities intelligently. Firefox, for instance, only downloads one file per element if it is idle and has no other tasks to carry out. It also completely ignores large files if the user has a slow network connection.

Nevertheless, prefetching is an excellent way to graphics and images in advance, which, for example are only needed after a Javascript action or a CSS hover. In an online shop, you could also prefetch the CSS files for the checkout part, as soon as the user has placed the first article in the shopping cart.

Subresource

<link rel="subresource" href="//en.ryte.com/image.jpg">

The subresource feature is comparable with . Here too, the specified file is downloaded from the server and stored in the browser's cache.

The difference here is in prioritising. As with prefetching, the browser decides whether and when the resource is necessary. The subresource however states that the file is highly important for the current website, and will be necessary shortly. In that sense, the browser attributes a much higher priority to the download.

If you aren't 100% sure that a resource will be necessary in the near future, you should opt for prefetch. Otherwise, you run the risk of blocking the download of other important resources when applying .

Preload

<link rel="preload" href="//en.ryte.com/image.jpg" as="image">

From July 2015, the preload feature was made available as a first W3C Working Draft. This is comparable with , but has a higher priority - the resources are made available as soon as they are required.

Prerendering

<link rel="prerender" href="//en.ryte.com/blog/">

The prerendering feature is the most powerful of the technologies presented here, but also carries most risk. Essentially ensures that a URL with all necessary static resources is fully loaded and set up in the background. You can imagine it as opening a URL in advance in a new tab, but it stays hidden until the user actually calls up the page. The load time while switching to a prerendered website is normally around 50 milliseconds; barely noticeable for the human eye.

Ultimately, all activities that would take place during an actual page impression, are carried out in the background. If for example you are logged in to an online shop and load the log-off page with the prerender, then you'll be logged off on the next page. You should also be careful when using your own tracking scripts (Google Analytics can deal with prerendering), since all Javascripts will be carried out completely. The can help, as they recognise, whether a website is actually being displayed.

There are some risks that come with prerendering. Ultimately, all activities that would take place when the URL is called up are executed in the background. For example, if you are logged into an online shop and load the unsubscribe page via preender, you are logged off the next time you call up the site. You should also be careful when using your own tracking scripts (Google Analytics can handle Prerender), as all Javascripts are also executed completely. The Page Visibility API can be used to find out whether a web page is actually being displayed.

When should I use which feature?

Generally, there’s never a one-size-fits-all solution. Every method has its pros and cons that need to be considered in the context of the website or project. If you have sufficient server capacities, preloading content often makes sense, and you should always consider prefetching or prerendering on websites where the next visitor interaction is predictable.

A few examples:

• Landing pages that have a call-to-action button leading to a sub page
• The URL of the next page when content is divided into several sub pages
• Picture galleries that are made up of several sub pages
• The next page of a search result, or an article overview on a blog

Dynamic preloading based on user interaction

Good preloading depends on precisely predicting user action. The examples above show that an initial preloading or rendering can make sense in a lot of cases. However, predictions become more precise if they are based on real user interaction.

Here are some examples:

• As soon as the user scrolls over the navigation arrows of an image slider with the cursor, the next image starts preloading.
• A sub page can be preloaded if it's detected that the cursor is going in the direction of the link.
• For pages that use lazy loading, you could use to preload images that are to be reloaded while scrolling, without limiting other browser tasks.

Finally, a simple Javascript or jQuery code snippet, with which all links on a page preload their URLs with a mouseover via . However, in this form, the code is not suitable for active use.