Re: [whatwg] Prefetch issues
On Thu, 10 Jun 2010, Eric Schurman 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? This was indeed a limitation of the prefetch mechanism. 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? No good reason. Fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Prefetch issues
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?
Re: [whatwg] Prefetch issues
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
Re: [whatwg] Prefetch issues
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
