[whatwg] Script preloading
dajdavies at gmail.com
Sat Jul 13 05:55:42 PDT 2013
On 12 July 2013 01:25, Bruno Racineux <bruno at hexanet.net> wrote:
> On browser preloading:
> There seems to an inherent conflict between 'indiscriminate' Pre-parsers/
> 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 balanced
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 the
> 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 and
> 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
> 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 <body>
> before the browser parses the document. I see an increasing potential need
> 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
Yoav Weiss has raised the idea of being able to use media queries with
scripts and other resources too.
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