Re: Prerender spec

Way late to the game here.. but better late than never. :-)

I'll second Robin's concerns. It is true that prender != prefetch (today),
but the more I think about it, the less I'm convinced that this is a useful
distinction. Specifically, while the developer has the context to know what
should be prefetched (or prerendered), based on analytics, expected user
workflow, etc., the UA is in a far better position to determine how far it
should go with these hints.

Further, based on experience in Chrome mobile.. prerendering would be a lot
more useful if it was smarter. Turns out we may not even have to "render"
the page to get significant rendering benefits!

A full doc outlining some ideas for "smarter prefetch" for mobile web:
https://docs.google.com/document/d/1wck0tFTiibKzZDuBeyK0lrKTKsZ5pqfvcR__1r2m834/edit#

Would love to hear everyones feedback / thoughts, etc.

ig


On Tue, Jul 2, 2013 at 7:48 PM, Arvind Jain <arvind@google.com> wrote:

> I agree with this.
>
> Re. "a" and "area" elements, I agree it applies there.
>
> Per Robin's suggestion, I'll send this to HTML WG.
>
> Arvind
>
>
>
> On Tue, Jul 2, 2013 at 4:01 PM, Jatinder Mann <jmann@microsoft.com> wrote:
>
>> 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
>>
>>
>>
>>
>