Prerendering allows you to load a single web page in the background when someone visits your site. The prerendered page is invisible to the end user until they click on a link to that page, at which point it appears to load at breakneck speed.
We’ve already talked about Google and Bing sometimes prerender the top ranking URL in their results pages. However, it’s a technique that anyone can use. Simply add “prerender” to a rel attribute in a <link> element: for example, <link rel=”prerender” href=”prerender-this-page.html”>. This is potentially useful when you’re sure that your visitors will be moving on from a particular page (as they might if it’s an article spanning several pages).
In this post, we thought we’d look at the potential performance cost to prerendering.
We set up a simple page and included a prerendered link to this site. We then tested the performance of the page with and without prerendering. Tests were carried out in Performance Analyser, using Chrome and Internet Explorer 11 (Firefox doesn’t support prerender).
The first thing to note is that we didn’t see any appreciable difference between the pages’ performance in Chrome:
Figure 1 – A filmstrip view of a Performance Analyser test in Chrome. The top page did no prerendering, while the bottom page prerendered http://community.nccgroup-webperf.com/.
However, in Internet Explorer the page that prerendered the community site was significantly slower. Figure 2 shows an extract from the filmstrip for one of these tests. The page without prerendering finished loading in 0.7 seconds, while the page that used prerendering was visually complete at 1.2 seconds.
Figure 2 – Filmstrip of two pages loading in Internet Explorer 11 – the bottom page is the one that prerendered a second URL
Why might this be?
You would expect a browser to prioritise the content on the source page and, if you take a look at the waterfall chart in Figure 3, you’ll see that it does just that. However, the browser also starts getting components on the prerendered page before the large background image on the source page (highlighted) has finished loading.
This suggests that bandwidth could be the problem (in this test it was throttled to 2Mbps), with the large image and the prerendered page effectively competing for it.
Figure 3 – A waterfall chart of a test in Internet Explorer 11 at 2Mbps – a slow-loading image is highlighted
To look at bandwidth, we tested the page on a private instance of WebPagetest at 1.5Mbps. Sure enough, it seemed to be the bottleneck:
Figure 4 – A slow-loading image in a test at 1.5Mbps. Bandwidth usage is highlighted at the bottom of the chart
So why isn’t this a problem in Chrome?
Chrome appears to prioritise the loading of components on the original page while bandwidth usage is high, delaying the loading of prerendered components:
Figure 5 – While bandwidth usage is high, it looks as though Chrome waits for all the objects on the original page to download before moving on to components on the prerendered page
Prerendering might be useful in some contexts, but if it slows down load for some users with Internet Explorer, the price looks too high.
var prelink = document.createElement(“link”);
We then tested the page again in Performance Analyser. Here’s an extract from the resulting waterfall chart:
The point to take away