It used to be that if we wanted to optimize our frontend assets, we would concatenate, minify, gzip etc. Don't get me wrong, we still do these things. Just that nowadays there are more steps we could take to increase performance on the frontend.
One of "these steps" we could take is called Resource Hinting. Resource hinting just like the name implies send hints to the browser "What Resource to get next?". Basically, we tell the web browser to load a particular resource before a user needs it. This can help us avoid DNS lookups, TCP connections, HTTPS handshakes etc.
Currently, there are four official ways to do this: preconnect, prefetch, dns-prefetch, prerender. Not in any particular order, we will start with DNS prefetching.
If you have a website, odds are you have Google analytics or some other form of third-party analytics installed on your site.
Not just analytics, anything that involves installing third-party script is overhead due to extra HTTP call(s). This also includes facebook widgets, twitter follow button widget, AD snippets, etc.
With DNS prefetching, we can tell the browser to perform a DNS lookup on the domains of these third party scripts, and when we finally make a request, we get only the file since we've already carried out DNS lookup before hand.
Doesn't sound like much right? Wrong, a DNS lookup can take as much as 1 - 3 seconds or higher in weird situations. Now, imagine you have at least 3 of this type of resource on your page. It means your website will be slow, and users hate slow websites.
To let the browser prefetch a domain DNS, you can add this little snippet to your website's
<link rel="dns-prefetch" href="http://example.com">
href should only point to the domain of the resource and not to the resource itself. Now, when the browser comes across this
<link tag on the page, it immediately starts performing a DNS lookup in the background, and when the resource gets called only a download is required, no more DNS lookup.
For browser support, DNS Prefetching has a large reach on desktop browsers, but still lacking when it comes to mobile browsers and of course older IE versions.
SpeedTest for DNS Prefetching
For this test we create two HTML pages that load a twitter follow button widget. One page will use
dns-prefetch and the other wont use it. Also, using chrome's inbuilt speed throttling, reduce the speed to 1Mbps and load both pages.
Here is the result without
dns-prefetch on this page.
dns-prefetch on this page.
Taking DNS prefetching a bit further, preconnect is basically dns-prefetch on steroids. If the domain you enabled prefetching for uses HTTPS, preconnect allows you to not only perform DNS lookups but also resolve TCP roundtrips, TLS negotiations etc.
If you thought DNS lookups were slow, TLS negotiations are slower as they involve a to and fro movement of SSL certificates for verification.
Enabling preconnect is simple, you just have to add a link tag with
href pointing to the domain where the resource is hosted.
<link rel="preconnect" href="https://cdn.example.com">
Preconnect is still lacking currently when it comes to browser support as only a few browsers support it. So, for now at least, only use DNS prefetching.
This allows you to go get an entire resource. For example, a font, an image. With prefetching, we can download and kept image in the browsers cache, and when the request for the file is made, the browser just looks in its cache and serves the file.
<link rel="prefetch" href="/path/to/resouce/image.png">
Currently, its implementations are not consistent. Take Firefox for example, it will only prefetch resources only when the browser is idle
But for browser support, only a few mobile browsers and the new internet explorer (not edge, Safari) don't support prefetching.
This is edge case, and should be used mostly when your user has a slow connection or when you are absolutely sure that your user will click on that link.
Prerendering makes loading a link instant, similar to searching with Google instant.
To preload a page, just add this
<link> tag to the page.
<link rel="prerender" href="http://example.com">
Note: this will download the entire page.
This has the worst browser support and should be used sparingly (at least for now).
Since we are not sure what a user does on the page, we could guess. For example, if a user scrolls past a certain part of the page, we could increase the probability of prerendering the next navigation page.
To set a probability, we need to add a new
pr attribute to the link tag with the value. The value for probability is a float ranging from 0 - 1.0.
<link rel="prerender" href="//example.com/page/2" pr="0.42">
This is just for a twitter button and bootstrap css on a CDN. A normal page could have more than that.
This is total speculation, and I don't have any tests or proof to back this up, but it seems only logical, loading too many widgets on your page will definitely slow down your website as will hinting at too many resources. Everything should be done in moderation.
In closing, predicting what a user does next is almost impossible, but it doesn't hurt to try, right?
To learn more about Resource hinting check out the W3 document.