W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2010

[whatwg] Prefetch issues

From: Eric Schurman <ericsc@gmail.com>
Date: Thu, 10 Jun 2010 09:50:56 -0700
Message-ID: <AANLkTinXjqK-W2H5qb3jWrl84oiQX5d_WpsK8U3MsUqZ@mail.gmail.com>
Like you do say, the link header doesn't work for exactly the same
reason - we'd have already flushed.
It does seem like adding rel=prefetch to A and AREA may be the best solution.


On Thu, Jun 10, 2010 at 9:46 AM, Peter Beverloo <peter at lvp-media.com> wrote:
> On Thu, Jun 10, 2010 at 17:01, Eric Schurman <ericsc at gmail.com> wrote:
>> As described, the link prefetching capability seems to have some
>> limitations that work counter to the performance of the page using it.
>>
>> It appears as though LINK elements are metadata elements and that
>> these may only be supported inside the HEAD of the document. If so,
>> then this is an issue in the real world, because at the time a web
>> server flushes chunks containing the HEAD section of a document, the
>> links we would want to prefetch are often not known. This is true for
>> all the large sites I've analyzed or worked at. For example, many
>> pages on a site will contain the same visual header, and we want to
>> flush the HEAD and visual header content while the server is in the
>> process of figuring out what the content of the page will be - which
>> will contain the links we'd like to prefetch.
>>
>> Am I reading this correctly? Or is there a something that would allow
>> the flushing scenario I describe above?
>>
>> One of the simplest approaches may be to add support for
>> rel="prefetch" to A and AREA's, but it's been explicitly excluded from
>> those. Why?
>>
>> Another approach could be to allow LINK throughout the document. This
>> would allow for prefetching content like images even if you didn't
>> know them at HEAD rendering time.
>>
>> Any opinions?
>>
>
> While I have not found the original discussion about including the
> prefetch relation in area and anchor tags, my guess would be that it's
> a feature that would quite easily be abused by web authors. Adding
> @rel="prefetch" to all anchors is a lot easier than putting them in
> the header, so why not just preload every page on the site? Again,
> someone else will probably have the answer you're looking for.
>
> Mozilla's Developer Center has a page about the attribute value[1]
> which already suggests that they might add the feature on normal
> anchor tags if there is sufficient interest in that. Their page also
> contains a chapter about how to implement prefetching using the Link
> HTTP header, which would be a solution if your website uses output
> buffering.
>
> Considering you're specifically talking about flushing the header
> before the links are known, however, I'm assuming that won't be a
> possibility either. The link tag is specifically used for metadata
> about the current document, so using that across the entire document
> doesn't sound like a good idea to me. Despite the possibility of abuse
> by authors, it seems to me that it's a fair use-case for including the
> attribute.
>
> Regards,
> Peter Beverloo
>
> [1] https://developer.mozilla.org/En/Link_prefetching_FAQ
>
Received on Thursday, 10 June 2010 09:50:56 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:24 UTC