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