[whatwg] Script preloading
bruno at hexanet.net
Sun Jul 14 19:17:40 PDT 2013
On 7/13/13 5:55 AM, "Andy Davies" <dajdavies at gmail.com> wrote:
>On 12 July 2013 01:25, Bruno Racineux <bruno at hexanet.net> wrote:
>> On browser preloading:
>> There seems to an inherent conflict between 'indiscriminate'
>> PreloadScanner and "responsive design" for mobile. Responsive designs
>> mostly implies that everything needed for a full screen desktop is
>> provided in markup to all devices.
>The pre-loader is a tradeoff, it's aiming to increase network utilisation
>by speculatively downloading resources it can discover.
>Some of the resources downloaded may be not be used but with good design
>and mobile first approaches hopefully this number can be minimised.
>Even if some unused resources get downloaded how much it matter?
>By starting the downloads earlier, connections will be opened sooner, and
>the TCP congestion window to grow sooner. Of course this has to be
>against visitors who might be paying to download those unused bytes, and
>whether the unused resources are blocking something on the critical path
>from being downloaded (believe some preloaders can re-prioritise resources
>if they need them before the preloader has downloaded them)
>Although we talk about *the preloader*, it's worth remembering different
>browsers (and versions) have different preloading approaches - compare the
>connection view charts (at bottom of page) for www.channel4.com in Chrome,
>Firefox and IE10 and you'll see subtle differences:
>> Isn't the Pre-parsers/PreloadScanner's inability to take into account
>> display[none:yes] factor be a potential significant blow to 'mobile'
>Use case: What if I have a set of images in an element set as
>> display:none; only designated to be show on desktop or tablet screens
>> not on mobile phone?
>> What if I have an inline script in that node?
>> Isn't the PreloadScanner loading a lot more than I need, a problem here?
>Challenge with this approach is the browser has to build the render tree
>before it can decide whether to download a resource i.e. download HTML,
>parse it, build a DOM, download CSS, parse it, build CSSOM, then build
Well the crazy idea I had in mind here, is more of a scenario like:
Download and parse HEAD, my script, download BODY, parse BODY, build a
DOM, "let me interact with the DOM with JS first", PreloadScanner, parse
whole new level of DOMReady approach :)
>> In addition to the need to preload, with responsive design taken into
>> consideration, and for lack of not being able to remove part of the
>> before the browser parses the document. I see an increasing potential
>> for the ability to indicate to the browser not to load selective assets
>> before DOMReady and suppress such preload.
>The proposed lazyload attribute should help here
Thanks for pointing that out. Interesting solution.
It's actually quite on topic with this thread. Noting that the 'lazyload'
proposal, which tries to do the opposite of preload, somewhat also
introduces a notion of dependencies with scripts and other elements via a
simple priority mechanism.
That is, as per current specs:
<script src="jquery-plugin1.js" lazyload></script>
<script src="jquery-plugin2.js" lazyload></script>
It implies that I want to load my plugins for later use, they depend on
jquery which will load and execute first, and the dependent scripts do not
delay the load of the document.
Now it'd be interesting to see how 'lazyload' deals with async or
async=false which is not fully specified. Or wether 'deferred' scripts
execution precedes 'lazyload' scripts or not. It a bit unclear there.
But in a sense 'lazyload' can defer a stylesheet evaluation like Garrett
And 'lazyload' has implications with such 'dependency' or 'whenneeded'
markup. It gets complicated.
>Yoav Weiss has raised the idea of being able to use media queries with
>scripts and other resources too.
Nods, raising the idea makes sense.
>Responsive design is young, I think we still have a lot to learn and it's
>going to take a while before we really understand what features we need.
More information about the whatwg