So, after scanning through the linked resources at the bottom of the article, it seems as though the `prefetch` and `prerender ` link relations are two different things.
The `prefetch` link relation[1] is registered with IANA, and is part of the HTML5 spec. Its use seems to be to prefetch & cache one asset for subsequent browser rendering.
The `prerender` link relation will tell the browser (chrome) to prefetch & cache an asset and all linked assets required for its rendering.
They seem like they both have a use but only one is part of the HTML5 spec, and it seems that prefetch was only ever implemented in firefox.
I know that Google wants a speedy experience for its users (more users), and it has pushed hard before with things like SPDY, but why not add to the spec rather than fragment?
You'll note that ``prerender`` is there as well as the ``subresource`` link relation which is a stronger form of ``prefetch`` stating that the resource will be used by the current page rather than likely to be used on subsequent pages. I did some benchmarks to compare the performance of each variation across the top three browsers:
I've tried it and it sort of works, I've had it on some of my sites for a while now. One thing that it doesn't seem to handle is the 'search results prefetching'. I have a dynamic table, and when a person types in their search terms, the table will filter, and if filtering results in 4 or less rows in the table, i'll add a prefetch to each of those links. However, what chrome does is start the request and then immediately cancel it. So the server's cache is warmed up, but the client still has to request the page.
So, Chrome supports prefetch but it seems to cancel the request immediately (you can see this with the network monitoring tool of chrome).
Anyway, here's their take on it, and it makes a lot of sense.
I have yet to experiment with this feature - seen it used on a few different websites. I am curious on how to handle prerender requests vs an actual visit. Is there a way to distinguish between the two?
I don't think there is a way server side to detect if the request is for a pre-render or not since I don't think it sends any special headers or anything like that.
The user won't know if the browser prefetched and prerendered the page before the click, so you should serve identical content in both cases.
The only issue is counters/analytics, but again, the server side must serve identical pages in both cases, only the browser side javascript could/should check if the page is actually viewed.
"If your site includes a third-party script for analytics or advertising, in many cases you shouldn't have to make any modifications to your site—the third party will simply modify the script they provide slightly to make use of the Page Visibility API. You should contact the third party directly to see if their scripts are prerender-aware."
I'd assume Adsense would of implemented this and would be prerender-aware.
With iframe you will be fetching all static resource which is already a win
But unless page-b is static with longer lived expiration, e.g. no `Pragma: no-cache` and so on, the browser may decide to fetch it again
Additionally you'll be rendering in a smaller frame, so re-rendering will likely be required. You can work around by sizing the iframe to match the window size, but that gets hacky. And you don't know what type of rendering work the browser may decide to do when you have display: none
But the iframe approach you suggest can be beneficial when:
* page-b's html depends on page-a's. HTML may be different but static resources are likely unchanged. Example: page-a is login screen and page-b is a members area.
* browser other than chrome
The iframe shouldn't be page-b , but some other page-c.html that only loads css, js, img and has no other content
I'm not even sure what side effects "display: none" would have here.. But that's beside the point. The point of prerendering is to to deliver an instant "swap" of the prerendered tab when the user navigates to that page - think of it as a hidden tab, which gets swapped in for your current one. As a result, the render is "instant". With iframe.. you obviously don't get that.
A bit late, but I wonder if any one knows of a reliable way to detect support for prefetch/prerender, without having to actually fire one off and see if it goes through?
[+] [-] darrhiggs|12 years ago|reply
The `prefetch` link relation[1] is registered with IANA, and is part of the HTML5 spec. Its use seems to be to prefetch & cache one asset for subsequent browser rendering.
The `prerender` link relation will tell the browser (chrome) to prefetch & cache an asset and all linked assets required for its rendering.
They seem like they both have a use but only one is part of the HTML5 spec, and it seems that prefetch was only ever implemented in firefox.
I know that Google wants a speedy experience for its users (more users), and it has pushed hard before with things like SPDY, but why not add to the spec rather than fragment?
[1] http://www.w3.org/TR/html5/links.html#link-type-prefetch
[+] [-] acdha|12 years ago|reply
http://microformats.org/wiki/existing-rel-values#HTML5_link_...
You'll note that ``prerender`` is there as well as the ``subresource`` link relation which is a stronger form of ``prefetch`` stating that the resource will be used by the current page rather than likely to be used on subsequent pages. I did some benchmarks to compare the performance of each variation across the top three browsers:
http://chris.improbable.org/experiments/browser/prefetch-tim...
[+] [-] nobodysfool|12 years ago|reply
So, Chrome supports prefetch but it seems to cancel the request immediately (you can see this with the network monitoring tool of chrome).
Anyway, here's their take on it, and it makes a lot of sense.
https://developers.google.com/chrome/whitepapers/prerender
[+] [-] igrigorik|12 years ago|reply
[+] [-] mdhgriffiths|12 years ago|reply
[+] [-] Tomdarkness|12 years ago|reply
http://www.w3.org/TR/2011/WD-page-visibility-20110602/
Supported in Chrome, Firefox and IE10.
MDN has some information on how to use it:
https://developer.mozilla.org/en-US/docs/Web/Guide/User_expe...
I don't think there is a way server side to detect if the request is for a pre-render or not since I don't think it sends any special headers or anything like that.
[+] [-] PeterisP|12 years ago|reply
The user won't know if the browser prefetched and prerendered the page before the click, so you should serve identical content in both cases.
The only issue is counters/analytics, but again, the server side must serve identical pages in both cases, only the browser side javascript could/should check if the page is actually viewed.
[+] [-] xur17|12 years ago|reply
If you are using adsense on your website, be careful: http://www.seroundtable.com/chrome-prefetch-bug-relnext-1643...
[+] [-] Tomdarkness|12 years ago|reply
If you read Google's own page on prerendering:
https://developers.google.com/chrome/whitepapers/prerender
"If your site includes a third-party script for analytics or advertising, in many cases you shouldn't have to make any modifications to your site—the third party will simply modify the script they provide slightly to make use of the Page Visibility API. You should contact the third party directly to see if their scripts are prerender-aware."
I'd assume Adsense would of implemented this and would be prerender-aware.
[+] [-] eggbrain|12 years ago|reply
If so, if I prerender a page that prerenders the first page, does this crash the browser?
[+] [-] Kallikrates|12 years ago|reply
[1] https://developers.google.com/chrome/whitepapers/prerender
[+] [-] simonw|12 years ago|reply
[+] [-] troels|12 years ago|reply
[+] [-] arkitaip|12 years ago|reply
[+] [-] mike-cardwell|12 years ago|reply
[+] [-] ssttoo|12 years ago|reply
But unless page-b is static with longer lived expiration, e.g. no `Pragma: no-cache` and so on, the browser may decide to fetch it again
Additionally you'll be rendering in a smaller frame, so re-rendering will likely be required. You can work around by sizing the iframe to match the window size, but that gets hacky. And you don't know what type of rendering work the browser may decide to do when you have display: none
But the iframe approach you suggest can be beneficial when: * page-b's html depends on page-a's. HTML may be different but static resources are likely unchanged. Example: page-a is login screen and page-b is a members area. * browser other than chrome
The iframe shouldn't be page-b , but some other page-c.html that only loads css, js, img and has no other content
[+] [-] igrigorik|12 years ago|reply
[+] [-] troels|12 years ago|reply
[+] [-] jjellyy|12 years ago|reply
They have compiled templates so you would get even better performance with no network requests.
[+] [-] Semaphor|12 years ago|reply