I recently began using a newish HTML5 feature called prerendering in the Soundslice registration process, and I'm very happy with how it's been working.
Prerendering is a way for you (as a web developer) to tell a web page to load (and render!) a second page in the background -- where the second page is one that's highly likely to be visited next.
Here's how it works. Say you have Page A and Page B, where the user always visits them in that order. You can put a bit of code in Page A's markup that says "prerender Page B right now." Thus, when the user visits Page A, her browser will download and render Page B in the background, such that when she clicks through to Page B, it's displayed nearly instantly, because all of the loading and rendering work has already been done. It's so fast it seems magical -- it must be experienced to be believed.
Prerendering is easy to do: just put a line of markup in Page A's <head>, like so:
<link rel="prerender" href="/path/to/page-b/">Note this apparently only works in Google Chrome at the moment, so the benefit is limited to that browser until other browsers implement it. But it's such an easy change that it's hard to justify not taking the few minutes to do it.
A multi-page form, as in a registration process, is a great use-case for prerendering. When you sign up for a Soundslice account, for example, first you get a form where you specify your username and password. Then, when you submit that, you get a form where you optionally upload an avatar and enter a profile. Then, when you submit that, you get the welcome/tutorial page. This is a very linear thing, where there's a very high probability that a user is visiting those pages directly in succession.
(Comparing the benefits of a single-page mega form vs. multi-page smaller forms is a separate discussion. Let's assume you have at least two pages in your site's registration process.)
In a multi-page registration process like this, prerendering works great -- as long as the pages don't depend on another. If the submitted data in Page A influences the markup of Page B, don't use prerendering between those two pages. (For example, this might be the case if the form on Page A includes a "username" field, and you then display "Welcome, [username]" on Page B.) On Soundslice registration pages, I'm in the clear because the pages don't depend on another.
Finally, there is a small downside to prerendering -- you're making your users load and render that next page whether they end up visiting the page or not. But in a tightly controlled multi-page experience like a registration process, you can be confident that most users will visit that next page. So if your pages don't depend on each other and there's a high probability they'll be visited in succession, I highly recommend this technique.
More info on prerendering: Google whitepaper, Ilya Grigorik article, Chris Ruppel article.
Comments
Posted by Peter Bengtsson on May 28, 2013, at 5:38 p.m.:
You can use `prefetch` for Firefox. See how I link to the home page from any blog post. For example on http://www.peterbe.com/plog/premailer-now-excludes-pseudo-selectors-by-default
This is based on the "assumption" that people who land on a blog post will next go to the home page.
Posted by APD on May 28, 2013, at 5:42 p.m.:
A demo would be cool
Posted by Jurian Sluiman on May 28, 2013, at 5:43 p.m.:
How does preloading function after POST? Server side processing can check if you have hit page A before you get page B returned (I.e., store the form data in a session and only if that's present, assume it's safe to go to page B).
If the browser simply performs a GET to page B, it will likely cause an error and that completely negate the effect of preloading. Could you elaborate? Note this is independent from the question where you need data from page A to be displayed onto page B.
Posted by Adrian Holovaty on May 28, 2013, at 6:09 p.m.:
Peter: Thanks for bringing up prefetch. That's different than prerender, because prefetch only fetches the document, no media files, and it doesn't actually render it. So it ends up being slower (but possibly still worth doing).
APD: Google has set up a demo page (http://prerender-test.appspot.com/). It appears to be a bit buggy for me (sometimes it says my browser supports prerendering, other times it doesn't), but when it works, it gives you a good sense of prerendering.
Jurian: I always do a redirect after successful POST requests, so prerendering works just fine for the page-that-the-user-is-redirected-to. Am I understanding your question correctly...?
Posted by Dudeson on May 28, 2013, at 7:15 p.m.:
Could you just sign up for a soundslice account for a demo? :P
Posted by Gabriel Martin on May 28, 2013, at 7:33 p.m.:
Actually, I just heard about this at another blog, so I figured I'd share that one, in case there are more cool features that you'd enjoy implementing. Happy coding!
daker.me/2013/05/5-html5-features-you-need-to-know.html
Posted by Cyranix on May 29, 2013, at 12:10 a.m.:
Following on from Jurian: Would it be accurate to say that pre-rendering is only viable if there are no dependencies between the main request and the pre-rendered request? If Page B intended to display a username that was assigned via POST from Page A, is there any upshot to attempting a pre-render on Page B, or any strategy to handle errors that would give you even partial benefit from pre-rendering?
Posted by Adrian Holovaty on May 29, 2013, at 1:08 a.m.:
Cyranix: If Page B depends on POST data from Page A, then prerendering would either not work or would prerender the wrong data (depending on what exactly Page B does with the data). I'd weigh the benefit of displaying the Page A data on Page B vs. the quicker loading time of Page B -- it's a judgment call.
Posted by Ilya Grigorik on May 29, 2013, at 3:23 a.m.:
Cyranix, Jurian Sluiman: re, POST and prerendering.. The answer is simple: we only prerender "safe" pages, and POST, exactly for the reasons you mentioned is not safe. Of course, you could also have a "non safe" GET request, but if you do, that's your own fault. :-)
I've documented some of the criteria and limitations for triggering prerendering here:
http://www.igvita.com/posa/high-performance-networking-in-google-chrome/#prerendering
Also, for other browser hints, take a look here:
http://chimera.labs.oreilly.com/books/1230000000545/ch10.html#BROWSER_OPTIMIZATION
Posted by Cyranix on May 29, 2013, at 5:29 a.m.:
I figured that "safe" requests would be the best use case, but wanted to make sure I wasn't overlooking something. Thanks for the confirmation and the info links!
Posted by Ezekiel Victor on May 30, 2013, at 9:50 a.m.:
Absolutely fantastic... Pro. ;)
Posted by Elias on May 30, 2013, at 1:12 p.m.:
How does this affect JavaScript/Ajax on the prerendered page? Does it execute and/or fetch remote data? One concern is skewing web analytics; resulting in inaccurate conversion tracking.
Posted by Matt Menke on June 3, 2013, at 3:15 p.m.:
Elias: Javascript is run. Loading flash/other plugins is deferred until the page is navigate to, and HTML5 audio/video cancels the page load. Once HTML5 media becomes more common, ideally we'll defer loading that as well.
A page can detect if it's being prerendered using the page visibility API (http://www.w3.org/TR/page-visibility/, https://developers.google.com/chrome/whitepapers/pagevisibility).
Unfortunately, if you can't run Javascript on the page, you can't detect if a request was from a prerender.
Posted by Joel on June 5, 2013, at 6:16 p.m.:
This is pretty awesome. Is this supported on mobile Chrome i.e. for iOS?
Posted by Mathew Porter on June 5, 2013, at 7:06 p.m.:
Ive been looking at the prerender markup and glad to see someone with a successful and functional implementation using it in a project.
Posted by Oliver Hankeln on June 7, 2013, at 1:33 p.m.:
This is a cool feature that I did not know. Thanks for posting this.
But please be careful where you use this feature. If you track pageviews through tracking pixels, your results will get inaccurate if you use this. And if you happen to have ad contracts based on measured PIs this might even be considered cheating.
Posted by Vasiliy Faronov on June 7, 2013, at 1:48 p.m.:
Hey, rel=prerender has nothing to do with HTML5. It is not mentioned in the W3C HTML5 spec, nor in WHATWG’s “living standard” (which already isn’t HTML5). It’s a vendor feature from Google.
Comments have been turned off for this page.