- From: James Robinson <jamesr@google.com>
- Date: Tue, 17 Jan 2012 16:37:38 -0800
On Tue, Jan 17, 2012 at 4:29 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote: > On 1/17/12 7:24 PM, James Robinson wrote: > >> Even this scheme doesn't work with a model like SPDY push or other >> bundling techniques or with more aggressive preloading that initiates >> loads before the main resource is loaded. >> > > Er... you mean it initiates loads before it has any idea whether the main > resource might have changed such that it no longer links to the objects in > question? > The way that these sorts of schemes work is that the server knows that a set of resources are needed in addition to the main resource and it starts sending them down before the client has received/parsed the main resource. The server serving foo.html can have a pretty good idea about whether foo.html contains the string "<script src=foo.js>" so there isn't any real reason for it to not serve foo.js at the same time assuming that the underlying protocol can handle such a thing. In situations with high RTTs and reasonable bandwidth (like common mobile networks) this can be a big win. I bring this up to make sure that we aren't making promises about resource loads that we can't keep. - James > > I agree that such aggressive preloading is impossible to control from the > source document; an interesting question is whether it's desirable. I know > that in the past when Gecko preloaded too aggressively we got huge > complaints from various ad providers about "bogus impressions".... > > > 1.) Monitoring/modifying/**preventing network activity for a given >> resource load >> >> 2.) Monitoring/modifying/**preventing DOM modifications that occur as the >> result of a resource load >> >> For (1) I can't think of any web-facing needs. >> > > I believe mobify does in fact want (1) as much as it can to conserve > bandwidth... > > > In any event I think that beforeload as it exists today is a bad API for >> the web >> > > Good, we agree on that. ;) > > > (although I suspect it'll stick around for extension contexts, which is >> more acceptable in my view). >> > > It's obviously just fine from my pov at that point. ;) > > -Boris >
Received on Tuesday, 17 January 2012 16:37:38 UTC