Re: Prerender spec

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