Re: [resource-hints] first spec draft

On Wed, Aug 13, 2014 at 1:05 AM, Yoav Weiss <yoav@yoav.ws> wrote:
>
>
>
> On Tue, Aug 12, 2014 at 1:33 PM, 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.
>
>
> Hi Jonas,
>
> Wouldn't we be able to get most of the benefits of what you're suggesting by
> <link rel=prerender>ing the common subresources of these target pages?
> Also, if you split the common HTML parts of these pages into HTML imports,
> you can prerender them as well.

Not really. You wouldn't have any JS libraries executed, and it's hard
to meaningfully process a CSS file without a DOM to apply it to.

/ Jonas

Received on Wednesday, 13 August 2014 17:00:56 UTC