Re: [resource-hints] first spec draft

On Tue, Jul 8, 2014 at 10:35 AM, Ilya Grigorik <igrigorik@google.com> wrote:
> First run at the spec based on previous discussions [1] and feedback:
> https://igrigorik.github.io/resource-hints/

Hi Ilya,

I haven't read through the spec yet, so apologies if this is something
that's already addressed. I'll try to find time to look through the
spec in a not too distant future since I'm very interested in seeing
the web gain this capability in a cross-browser way.

In the meantime, I'd like to mention a use-case we've come across as
we've looked at prerendering in Firefox and FirefoxOS.

The way that prerender has traditionally been used is to enable a
webpage to load and render a URL that the page thinks it's likely that
the user is going to navigate to next.

This fits well for situations like the google search results page, or
a multi-page news article, where there's a good chance that the page
can guess where the user is going next.

However for something like a bugzilla search results page, there's
both problems and opportunities to improve. Consider the page at

https://bugzilla.mozilla.org/buglist.cgi?quicksearch=preload

This is a page containing a large list links to "bug pages". Each "bug
page" looks very similar, but has a different URL and contains
information about a different bug. It's going to be very hard to guess
which link the user is going to click, and even if we developed some
good heuristics about which link is most likely to be clicked, many
times that guess will be wrong.

However, in almost all cases the user will click one of the links to a
bug page. And all bug pages share a lot of common UI elements. I.e.
each bug page has the same header and footer, and uses the same
stylesheets, JS and images.

It would be great if we could here enable prerendering of the common
parts of the various bug pages. So that only the bug specific data
needs to be loaded and inserted into a prerendered page when the user
clicks the link for a bug.

This can actually be accomplished fairly easily. Two options for how
to solve this are:

1. Enable a page which contains a <link rel=prerender> to open a
postMessage based communication channel with the prerendered page.
Also define that if the prerendered page uses replaceState to change
it's URL, the prerendered page is used if the user navigates to a URL
which matches the new URL, rather than the URL appearing in the <link
rel=prerender>
2. Enable a prerendered page to declare a URL pattern which it
"captures". So that if the user navigates from the original page to
any URL which matches the URL pattern, the prerendered page is used.

I like the first solution better since it's more flexible. And it
allows things like enabling the search results page to tell the bug
page to start loading data for the relevant bug as soon as the user
hovers a link, before the link is clicked.

Other examples of this use case are:
* Rendering a contact list where clicking on a contact takes you to a
page with contact details.
* The search result page when doing a product search on amazon.

Another example of where this is needed is when building search UIs
(putting aside search UIs which are able to render the search results
live as the user types). For example Amazon's search bar, or even the
bugzilla search UI. Once the user start typing a search, we can make a
very good guess that the user is soon going to navigate to a search
results page.

However search result pages often contain the search string in the URL
(and it would be a good thing if more websites did). This means that
we won't know the final URL to preload until the user is done typing
in the search query and modifying any other search parameters.

However large parts of the search results page will be constant and
could be loaded in advanced and prerendered.

Using either of the above two solutions would enable the search UI to
use a <link rel=prerender> to load a page which contains the search
results UI and then once the user submits the search query just load
the relevant search data and insert into the prerendered page.

In this case solution 1 has further benefits since the search UI could
actually continuously let the prerendered page know what the current
search parameters are such that the prerendered page could start
loading data as the user is adjusting the search parameters.

/ Jonas

Received on Tuesday, 12 August 2014 11:34:26 UTC