2011/1/20 Gavin Peters (蓋文彼德斯) <[email protected]>: > I also have thought about how we can go forward, I'd like folks > comments on this: > > Step 1: Land bug 51941, a refactoring of the HTMLLinkPrefetch element > which pulls out loading for rel types prefetch, icon and dns-prefetch.
That sounds like a reasonable first step if we want to go forward with Steps 4 and 5. Perhaps it would make sense to delay this work until we're ready to do Step 4? > Step 2: Add beforeload to at least prefetch & icon rel types, and hey, > why not dns-prefetch too! Do this to fix bug 52577. It seems reasonable to add beforeload events to prefetch. Icon is probably worth doing too. I'm less sure about dns-prefetch because that doesn't actually generate a "load" so to speak. Maybe leave it off in the first iteration? My slight reservation here is that, from a privacy standpoint, there's no reasonable way to prevent a web site from leading information back to its server. However, many privacy extensions take a "best effort" approach rather than an "airtight" approach. In that sense, generating these events seems valuable because it improve what these folks can build. > Step 3: Add rel type subresource (same as rel type prefetch, only > higher priority for in-page resources) (need to create a bug for > this). This seems valuable. My understanding is that subresource is similar to prefetch, just with a different priority (i.e., "please prefetch this URL in time for it to be used by a subresource of this page"). > Step 4: Add Link header, providing rel types subresource, prefetch & > dns-prefetch only (currently bug 51940). This step also makes sense to me because these headers don't modify the semantics of the document. Supporting them in headers means that web sites can optimize their performance using middleware boxes without hacking up their HTML. > Step 5: Add beforeload events to the Link header (as a followup after > bug 51940). This seems somewhat odd to me, but I guess it makes sense. There's some question about where to fire these events, but presumably firing them on the document itself would be fine. I'm willing to believe that my perspective might be biased because I've been talking to Gavin about these features for a while. I certainly don't want us to move forward here if folks don't think this is a beneficial course of action. Adam _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
