Re: [resource-hints] first spec draft

Thanks Jonas, this is really interesting. Followed up with some thoughts on
the mozilla.dev.platform thread:
https://groups.google.com/forum/#!msg/mozilla.dev.platform/AJYraXio-Fc/SD9mqdATaxwJ

ig


On Tue, Aug 12, 2014 at 4:33 AM, Jonas Sicking <jonas@sicking.cc> wrote:

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