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