Using HTML5 prerendering to speed up a multi-page registration process | Hacker News Reader

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

holovaty.com

99 pointsadrianh27 comments

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

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

[As per the HTML5 spec](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_...

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...

Thanks for the links.

I tend to use link relations for APIs; I hadn't realised that the HTML5 spec linked to a different registry.

A comparison of the different hints, and which browsers support them: http://chimera.labs.oreilly.com/books/1230000000545/ch10.htm...

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?

There is the page visibility API:

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.

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!

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.

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.

Looks pretty interesting.

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

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

"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.

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.

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?

your nick doesn't do you justice.

It wasn't meant as an insult - honestly!

I bet Chrome's implementation of this is super-careful about avoiding loops or going deeper than one level.

"... 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

List Https as reason to not prerender. There goes the idea of using it for a sales funnel.

I would imagine that it doesn't prerender the next page until the first is actually displayed.

Yep, that's how it's implemented.

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?

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?

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.

Because everyone uses one page MVCs?

Reply on news.ycombinator.com