Re: [resource-hints] first spec draft

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


Maybe the better answer is “it depends”. If you are operating over a high latency network, then most of the benefit is in fetching resources early over the network.

Peter


On Aug 13, 2014, at 12:59 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> 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:57:49 UTC