RE: Prerender spec

Robin,

Prefetch and prerender, while similar concepts, are different enough that we would want to have developers specify when they want one versus the other. From a resource utilization point of view, prefetch is relatively cheap compared to prerender, as the browser is just downloading the HTML as opposed to creating a hidden tab and navigating to it. The difference here is the browser is only exercising the networking subsystem for prefetch, but exercising all the subsystems for prerender (e.g., network, HTML parsing, CSS parsing, JavaScript, DOM, formatting, block building, layout, rendering, etc.). 

From a developer point of view, both features have value. For example, a news site may want to prefetch the root HTML for all of the articles on the page, since the pages are new and unlikely to be cached. On the other hand, to conserve system resources, the browser may limit the number of pages it will prerender, so we’d want the developer to only mark pages with prerender that they expect a high likelihood that the user will be visiting. E.g., in the news site this may be the main headline article. If we only provide the ‘prefetch’ tag and let the browser guess what this means, the browser will be forced to guess whether the user just wanted to cache that page or navigate to the page in a hidden tab, and may make mistakes.

I think we should keep both 'prefetch' and 'prerender'.

Thanks,
Jatinder


-----Original Message-----
From: Robin Berjon [mailto:robin@w3.org] 
Sent: Friday, June 21, 2013 3:59 AM
To: Philippe Le Hegaret
Cc: Arvind Jain; public-web-perf; Chris Bentzel
Subject: Re: Prerender spec

Hi all,

I'm jumping in the middle of this with somewhat limited context, sorry if I'm missing something.

On 14/06/2013 18:56 , Philippe Le Hegaret wrote:
> On Fri, 2013-06-14 at 09:23 -0700, Arvind Jain wrote:
>> Do folks agree? Or should there be a separate document?
>>
> I guess it depends on the size and the level of buy-in. Usually, it's 
> preferred to do an extension spec to start with but, in this case, it 
> seems an overkill.

I agree that an extension spec for this seems way overkill. The primary advantage of doing that would be to not have to worry about synchronising with us too much. But given the size of the feature I doubt that would be a major issue.

If you want to push this forward, I would recommend to start with simply bringing it to the HTML WG as a proposal (in email, much like the below).

My (personal) push-back on this would be about whether it is really valuable for UAs, in addition to prefetch. Both prefetch and prerender are hints, with behaviour largely left up to the UA. My question would therefore be: what is that prevents a browser from seeing a prefetch link and in fact prerendering it? Is this something that would not be decidable subject to some given heuristics? Failing that — and perhaps more importantly — are developers likely to choose between the two wisely?

The latter question is particularly important, because if the answer tends to be "no", then you're back to treating prefetch and prerender as the same thing, and requiring some form of heuristic to decide when to load.

Note that I'm not turning your proposal down here — I'm just pointing out the questions that will need answering in order to move this forward. I'm not a performance expert; the odds are that you have very good answers I haven't thought of.

> Any reason why this can't be applied to a and area elements, like 
> prefetch?

IMHO if it's on link it ought to be on those two as well.

--
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Tuesday, 2 July 2013 23:03:39 UTC