Pre-rendering with Chrome

[Brian Woosley]

To Chrome development team,

We're a social networking website (www.empowr.com) and use the prerendering feature in Chrome <https://www.chromium.org/developers/design-documents/prerender> to prepare another page of work in the background while the user finishes working on the current page, which can take from 30 seconds to a few minutes per page and can trigger a couple AJAX requests and temporary pop-up browser windows before the user advances to the next page.  This parallelizes the work done by the user and by the browser so that the user spends minimal time waiting for the network.

 

(1)  Our use case of prerendering the next page of work for a user actively using the browser tab despite activity in other tab is being considered as part of the feature design.  We have gotten reports that prerendering works more reliably when other tabs are closed, and we feel that shouldn’t influence the behavior of the currently active tab.

 

(2)  We are looking for guidance that we can tell users when prerendering is failing.   This guidance can be prewritten or can be prompted by automated heuristics that we add to the site using JavaScript.  In particular, these final prerendering statuses in https://src.chromium.org/svn/trunk/src/chrome/browser/prerender/prerender_manager.cc are ones we don’t have recommendations for our users, and we’re wondering what our guidance should be:

 

FINAL_STATUS_NON_EMPTY_BROWSING_INSTANCE

FINAL_STATUS_NAVIGATION_UNCOMMITTED

FINAL_STATUS_PAGE_BEING_CAPTURED

FINAL_STATUS_CANCELLED

FINAL_STATUS_WINDOW_OPENER

FINAL_STATUS_WOULD_HAVE_BEEN_USED

Any guidance you could provide us would be greatly appreciated.

Best,

Brian Woosley

Executive Vice President

www.empowr.com

[Matt Menke]

The <link> tag for prerendering emits events when the prerender starts that you can listen to on the page initiating the prerender - https://wiki.whatwg.org/wiki/Link_prerender_events.

Prerenders are very expensive objects, in terms of memory, CPU, and bandwidth, so we globally limit the number of total prerenders.  We also rate limit prerenders.  You could well be running into one of those behaviors.  If you can reproduce the lack of prerendering locally, you can go to about:net-internals#prerender in Chrome to see why a page wasn't prerendered.

FINAL_STATUS_NON_EMPTY_BROWSING_INSTANCE:  I'm not too familiar with this, but tabs that can talk to each other share a browsing instance.  If the tab launching a prerender has another tab that it can talk to, we abort the prerender.  I assume this is because the prerender can't talk to the other tab, and having two tabs talking to the other tab at the same time, when it only expects one, is problematic.

FINAL_STATUS_NAVIGATION_UNCOMMITTED:  This is a quirk of how things are implemented.  If we haven't committed the page being prerendered yet (Received last byte of headers / first byte of body, and sent it to a renderer process), we can't commie the prerender.  If the background work you do delays sending the main frame response, you could be running into this.  If you are, you could be sure to send the headers (And maybe the first byte of the body - though I don't think that's needed) before you start doing whatever work it is you need to do, server side.  If that's not the case, then you'll only see this for very fast navigations.

FINAL_STATUS_PAGE_BEING_CAPTURED:  This means we're taking a screenshot of the original page, like for the new tab page.

FINAL_STATUS_CANCELLED:  This happens if you remove the prerender <link> element from your page.

FINAL_STATUS_WINDOW_OPENER:  If the prerender would have had an opener it would talk to, we can't use the prerender.  Similar to the browsing instance one, I believe.

FINAL_STATUS_WOULD_HAVE_BEEN_USED:  This is for field trials, which I believe have all expired.  Users in the trial don't actually use prerenders, for data collection purposes.

[Brian Woosley]

Matt,

Thank you for the quick response!

We're interested in detecting when prerendering has completed loading the next page.  The prerender test site <http://prerender-test.appspot.com/> uses a StorageEvent to indicate when the prerendered page is ready, but when we implemented this strategy, the event doesn't fire in Chrome (but it does in Internet Explorer).  We've verified that the event handler is connected before the prerendered page signals localStorage.

Our particular implementation has the LINK element declared statically in the page HTML, and the prerendered URL redirects (HTTP status code 302) to the intended page.  All pages are on the same domain.

(1)  Is the localStorage mechanism intended to work?  The Web Storage specification says the event is only supposed to fire on windows other than the current window, and prerendered pages might be considered to be hosted in the same window.  Also, the explanation for FINAL_STATUS_NON_EMPTY_BROWSING_INSTANCE suggests that the prerendered page is not meant to be able to communicate with other windows.

(2)  Are there alternative mechanisms that we can use to detect the readiness of the prerendered page?

Best,

Brian

---

From: mme...@google.com <mme...@google.com> on behalf of Matt Menke <mme...@chromium.org>
Sent: Wednesday, May 11, 2016 3:28:22 PM
To: Brian Woosley
Cc: prer...@chromium.org
Subject: Re: Pre-rendering with Chrome

 

[Matt Menke]

https://wiki.whatwg.org/wiki/Link_prerender_events list events that we support.  Looks to me like they're all actually still vendor prefixed to me (webkitprerenderstopevent, webkitprerenderdomcontentloadedevent, etc).  We still tests for them, that are all passing.  I'm not sure if IE implements these (with or without its own vendor prefix).

The FINAL_STATUS_NON_EMPTY_BROWSING_INSTANCE is for a case where prerenders can't really be hacked into an existing API.  Whether localStorage should work or not is open for debate, I'm honestly not up to date on it, or how it's wired up in Chrome.