- From: Yoav Weiss <yoav@yoav.ws>
- Date: Mon, 27 Jan 2014 09:03:49 +0100
- To: Bruno Racineux <bruno@hexanet.net>
- Cc: WHATWG <whatwg@lists.whatwg.org>, Qebui Nehebkau <qebui.nehebkau+whatwg@gmail.com>
On Mon, Jan 27, 2014 at 4:20 AM, Bruno Racineux <bruno@hexanet.net> wrote: > > > On 1/26/14 3:39 PM, "Qebui Nehebkau" <qebui.nehebkau+whatwg@gmail.com> > wrote: > > >On Sat, Jan 25, 2014 at 4:13 AM, Bruno Racineux <bruno@hexanet.net> > wrote: > >> What exactly do you find misguided, can you be more specific? > > > >Basically, - and I'm trying not to over-elaborate here, since my > >opinion isn't really very important - I just mean that I don't think > >there should be any guarantees about how (or whether) browsers will > >preload, nor any specific means of controlling this, because the way > >resources get loaded is not really any of the author's business. > > I couldn't disagree more. It is my business to know how the browser loads > assets in order to better assist the best performance for my users. > Preloaders have been a great source of competitive innovation for browsers. Specifying it would at least partly prevent that. What is it exactly that you think needs specifying? > > Don't want to over-elaborate either but I'll leave you with a relevant > quote: > > "The good news is all of these optimizations are done automatically on our > behalf and often lead to hundreds of milliseconds of saved network > latency. Having said that, *it is important to understand how and why > these optimizations work under the hood*, because we *can* assist the > browser and help it do an even better job at accelerating our > applications." > > Ilya Grigorik - High Performance Browser Networking > http://chimera.labs.oreilly.com/books/1230000000545/ch10.html#BROWSER_OPTIM > IZATION > > > There is a balance between putting DOM loading on auto-pilot, blindly > assuming the preloader is your friend and can do no wrong, and the reality > that the preloader can't ultimately do the best job on its own. It needs > to be assisted with resource priority attributes (or preferably css) for > better control. Without them, the preloader is no more than a 'seen-first > priority' faster loader, with a priority agnostic performance shortfall. > > > >the argument that preloaders > >can't consider CSS isn't compelling to me, because a browser's choice > >to preload an image or not isn't important enough (or, I think it > >shouldn't be) to justify entrenching in a specification. > > If not for specifications, we certainly need 'preload opt-out' tools to > better manage loading priorities. Whether it be 'postpone', 'lazyload' or > said implications of 'hidden', and some documentation as to what to expect > from preloaders. > > > +1 for documentation (I'm trying to do my part on that front [1]) Can you please sum up what is the required use-case you think 'hidden' should handle that 'postpone' and 'lazyload' cannot? Yoav [1] http://calendar.perfplanet.com/2013/big-bad-preloader/
Received on Monday, 27 January 2014 08:04:13 UTC