W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2014

Re: [whatwg] 'hidden' as resources control

From: Yoav Weiss <yoav@yoav.ws>
Date: Mon, 27 Jan 2014 09:03:49 +0100
Message-ID: <CACj=BEi4nR2MjbxwfoYrx-1KYbaaNKN0yBbpofFvP307n_PBEA@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:15 UTC