I'm changing this from a simple discussion to a more formal proposal.
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. This would also avoid all of the
separate implementations of javascript precaching libraries that are
popping up.
Any opinions?
On Thu, Jun 10, 2010 at 9:50 AM, Eric Schurman eri...@gmail.com wrote:
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 pe...@lvp-media.com wrote:
On Thu, Jun 10, 2010 at 17:01, Eric Schurman eri...@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
