10 ms·

Using HTML5 prerendering to speed up a multi-page registration process

99 points by adrianh 13y ago

mdhgriffiths 13y ago
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?
- Tomdarkness 13y ago
  There is the page visibility API: http://www.w3.org/TR/2011/WD-page-visibility-20110602/ 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_experience/Using_the_Page_Visibility_API 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.
  - bjackman 13y ago
    So to tell if you're dealing with a pre-render request or an actual view you have to stick a load of AJAX in your page to make another whole HTTP connection from the users browser? Am I missing something here? Because that really sucks!
    - Tomdarkness 13y ago
      How else can you deal with it though? The whole point of the prerendering is that it fetches and renders the page in the background to be displayed to the user when they click on the link. You can't handle the prerender request differently because if the user clicks on the link then chrome will just display the prerendered page it fetched earlier and the user would expect to see the exact page as if they had clicked on a non-prerender link. If the page you are linking to is time sensitive then you should not be using pre-rendering.
- PeterisP 13y ago
  Why should you distinguish them? 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 13y ago
Looks pretty interesting. If you are using adsense on your website, be careful: http://www.seroundtable.com/chrome-prefetch-bug-relnext-16431.html http://www.seroundtable.com/chrome-prefetch-bug-relnext-1643...
- Tomdarkness 13y ago
  How do we know that was the cause of his adsense ban? If you read Google's own page on prerendering: https://developers.google.com/chrome/whitepapers/prerender 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.
  - teraflop 13y ago
    The summary on Search Engine Roundtable seems to be a bit of a fabrication; I don't see anybody in that forum thread claiming to have been banned from AdSense.
darrhiggs 13y ago
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? [1] http://www.w3.org/TR/html5/links.html#link-type-prefetch http://www.w3.org/TR/html5/links.html#link-type-prefetch
- nobodysfool 13y ago
  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. https://developers.google.com/chrome/whitepapers/prerender https://developers.google.com/chrome/whitepapers/prerender
- acdha 13y ago
  [As per the HTML5 spec](http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#other-link-types http://www.whatwg.org/specs/web-apps/current-work/multipage/...) new values are proprosed in the microformats wiki: http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions 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-timing.html http://chris.improbable.org/experiments/browser/prefetch-tim...
eggbrain 13y ago
Does this chain all the way down? Aka if my prerendered page also contains a link that prerenders a page, does that page get loaded too? If so, if I prerender a page that prerenders the first page, does this crash the browser?
- arkitaip 13y ago
  your nick doesn't do you justice.
  - arkitaip 13y ago
    It wasn't meant as an insult - honestly!
- simonw 13y ago
  I bet Chrome's implementation of this is super-careful about avoiding loops or going deeper than one level.
- Kallikrates 13y ago
  "... Some of the reasons prerendering might not happen: ... * Chrome encountered another prerender directive within the last 500 ms." [1] [1] https://developers.google.com/chrome/whitepapers/prerender https://developers.google.com/chrome/whitepapers/prerender
  - adrr 13y ago
    List Https as reason to not prerender. There goes the idea of using it for a sales funnel.
- troels 13y ago
  I would imagine that it doesn't prerender the next page until the first is actually displayed.
  - igrigorik 13y ago
    Yep, that's how it's implemented.
mike-cardwell 13y ago
Why would I: <link rel="prerender" href="/path/to/page-b/"> Instead of: <iframe src="/path/to/page-b/" style="display:none;"> What am I missing?
- ssttoo 13y ago
  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
- igrigorik 13y ago
  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.
jjellyy 13y ago
seems obsolete with one page MVC's like backbone and ember. They have compiled templates so you would get even better performance with no network requests.
- Semaphor 13y ago
  Because everyone uses one page MVCs?
troels 13y ago
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?

99 points by adrianh 13y ago

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?

Tomdarkness 13y ago
There is the page visibility API: http://www.w3.org/TR/2011/WD-page-visibility-20110602/ 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_experience/Using_the_Page_Visibility_API 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.
- bjackman 13y ago
  So to tell if you're dealing with a pre-render request or an actual view you have to stick a load of AJAX in your page to make another whole HTTP connection from the users browser? Am I missing something here? Because that really sucks!
  - Tomdarkness 13y ago
    How else can you deal with it though? The whole point of the prerendering is that it fetches and renders the page in the background to be displayed to the user when they click on the link. You can't handle the prerender request differently because if the user clicks on the link then chrome will just display the prerendered page it fetched earlier and the user would expect to see the exact page as if they had clicked on a non-prerender link. If the page you are linking to is time sensitive then you should not be using pre-rendering.
PeterisP 13y ago
Why should you distinguish them? 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 13y ago

Looks pretty interesting. If you are using adsense on your website, be careful: http://www.seroundtable.com/chrome-prefetch-bug-relnext-16431.html http://www.seroundtable.com/chrome-prefetch-bug-relnext-1643...

Tomdarkness 13y ago
How do we know that was the cause of his adsense ban? If you read Google's own page on prerendering: https://developers.google.com/chrome/whitepapers/prerender 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.
- teraflop 13y ago
  The summary on Search Engine Roundtable seems to be a bit of a fabrication; I don't see anybody in that forum thread claiming to have been banned from AdSense.

darrhiggs 13y ago

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? [1] http://www.w3.org/TR/html5/links.html#link-type-prefetch http://www.w3.org/TR/html5/links.html#link-type-prefetch

nobodysfool 13y ago
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. https://developers.google.com/chrome/whitepapers/prerender https://developers.google.com/chrome/whitepapers/prerender
acdha 13y ago
[As per the HTML5 spec](http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#other-link-types http://www.whatwg.org/specs/web-apps/current-work/multipage/...) new values are proprosed in the microformats wiki: http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions 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-timing.html http://chris.improbable.org/experiments/browser/prefetch-tim...

eggbrain 13y ago

Does this chain all the way down? Aka if my prerendered page also contains a link that prerenders a page, does that page get loaded too? If so, if I prerender a page that prerenders the first page, does this crash the browser?

arkitaip 13y ago
your nick doesn't do you justice.
- arkitaip 13y ago
  It wasn't meant as an insult - honestly!
simonw 13y ago
I bet Chrome's implementation of this is super-careful about avoiding loops or going deeper than one level.
Kallikrates 13y ago
"... Some of the reasons prerendering might not happen: ... * Chrome encountered another prerender directive within the last 500 ms." [1] [1] https://developers.google.com/chrome/whitepapers/prerender https://developers.google.com/chrome/whitepapers/prerender
- adrr 13y ago
  List Https as reason to not prerender. There goes the idea of using it for a sales funnel.
troels 13y ago
I would imagine that it doesn't prerender the next page until the first is actually displayed.
- igrigorik 13y ago
  Yep, that's how it's implemented.

mike-cardwell 13y ago

Why would I: <link rel="prerender" href="/path/to/page-b/"> Instead of: <iframe src="/path/to/page-b/" style="display:none;"> What am I missing?

ssttoo 13y ago
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
igrigorik 13y ago
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.

jjellyy 13y ago

seems obsolete with one page MVC's like backbone and ember. They have compiled templates so you would get even better performance with no network requests.

Semaphor 13y ago
Because everyone uses one page MVCs?

troels 13y ago

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?