[whatwg] Script preloading

Brian Kardell bkardell at gmail.com
Thu Aug 29 05:58:24 PDT 2013

On Aug 29, 2013 1:21 AM, "Jonas Sicking" <jonas at sicking.cc> wrote:
> Hi Ryosuke,
> Based on the feedback here, it doesn't sound like you are a huge fan
> of the original proposal in this thread.
> At this point, has any implementation come out in support of the
> proposal in this thread as a preferred solution over
> noexecute/execute()?
> The strongest support I've seen in this thread, though I very well
> could have missed some, is "it's better than status quo".
> Is that the case?
> / Jonas
> On Wed, Aug 28, 2013 at 7:43 PM, Ryosuke Niwa <rniwa at apple.com> wrote:
> > On Jul 13, 2013, at 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
> >> by speculatively downloading resources it can discover.
> >>
> >> Some of the resources downloaded may be not be used but with good
> >> and mobile first approaches hopefully this number can be minimised.
> >>
> >> Even if some unused resources get downloaded how much it matter?
> >
> > It matters a lot when you only have GSM wireless connection, and barely
loading anything at all.
> >
> >> By starting the downloads earlier, connections will be opened sooner,
> >> the TCP congestion window to grow sooner. Of course this has to be
> >> against visitors who might be paying to download those unused bytes,
> >> whether the unused resources are blocking something on the critical
> >> from being downloaded (believe some preloaders can re-prioritise
> >> if they need them before the preloader has downloaded them)
> >
> > Exactly.  I'd to make sure whatever API we come up gives enough
flexibility for the UAs to decide whether a given resource needs to be
loaded immediatley.
> >
> >
> >
> > On Jul 12, 2013, at 11:56 AM, Kyle Simpson <getify at gmail.com> wrote:
> >
> >> My scope (as it always has been) put simply: I want (for all the
reasons here and before) to have a "silver bullet" in script loading, which
lets me load any number of scripts in parallel, and to the extent that is
reasonable, be fully in control of what order they run in, if at all,
responding to conditions AS THE SCRIPTS EXECUTE, not merely as they might
have existed at the time of initial request. I want such a facility because
I want to continue to have LABjs be a best-in-class fully-capable script
loader that sets the standard for best-practice on-demand script loading.
> >
> >
> > Because of the different network conditions and constraints various
devices have, I'm wary of any solution that gives the full control over
when each script is loaded.  While I'm sure large corporations with lots of
resources will get this right, I don't want to provide a preloading API
that's hard to use for ordinary Web developers.
> >
> >
> > On Jul 15, 2013, at 7:55 AM, Kornel Lesiński <kornel at geekhood.net>
> >
> >> There's a very high overlap between module dependencies and <script
dependencies> proposal. I think at very least it would be useful to define
<script dependencies> in terms of ES6 modules, or even abandon markup
solution to avoid duplicating features.
> >>
> >> ES6 modules however do not solve the performance problem. In fact they
would benefit from UA having a list of all dependencies up front (otherwise
file's dependencies can only be discovered after that file is loaded, which
costs as many RTTs as the height of the dependency tree).
> >>
> >> So I think that eventually ES6 modules + link[rel=subresource] could
be the answer. The <link> would expose URLs to (pre)load for performance,
but modules would handle actual loading/execution for flexibility and
> >
> >
> > Yes, we should definitely consider how this preloading API works with
ES6 modules.
> >
> >
> >
> > On Jul 22, 2013, at 3:22 PM, Jonas Sicking <jonas at sicking.cc> wrote:
> >
> >> Having the load event anytime we are done with a network request also
> >> seems beneficial. Rather than having most APIs use "load" whereas this
> >> would use "preload".
> >>
> >> Generally speaking "load" means "loaded and processed". The
> >> 'noexecute' flag would change what the "and processed" piece includes.
> >
> > I don't think it'll be confusing if the script had noexecute.  We can
even call it noautoexecute if we wanted.
> >
> >> But I'm fine either way here. The same question and risk of confusion
> >> seems to exist with the "whenneeded" attribute. In general
> >> "whenneeded" seems very similar to "noexecute", but with a little bit
> >> more stuff done automatically, for better or worse.
> >
> > I like the simplicity of noexecute and excute().  However, I'm a little
worried that it doesn't provide any information as to how important a given
script is.  So Web browsers have no choice but to request all scripts
> >
> > I'd like to eventually provide APIs that allow authors to codify which
scripts are "vital" so that Web browsers can properly prioritize each
script request.
> >
> > Implementation wise, noexecute/execute() will be extremely easy to
implement in WebKit.
> >
> >> I.e. something like:
> >>
> >> <script src="script1.js" id="s1">
> >> <script src="script2.js" dependencies="s1">
> >>
> >> would run correctly in downlevel browsers, but would force the scripts
> >> to be blocking.
> >>
> >> <script src="script1.js" id="s1" async>
> >> <script src="script2.js" async dependencies="s1">
> >>
> >> would give you performant non-blocking behavior in downlevel browsers,
> >> but at the expense of the scripts not always running in scripts in the
> >> right order.
> >
> > Use defer instead?
> >
> > - R. Niwa
> >

I didn't get to it until this morning, but several folks on twitter have
made the same general point I would toss in so let's move it here:

"@slicknet: @Hixie @paul_irish this proposal conflates preloading with
dependency management. I would ignore the latter (as I did originally)."

"@paul_irish: @slicknet @Hixie I feel similarly. Adding HTML semantics for
dep mgmt duplicates the work of AMD/CJS and ES6 modules.
#writingemailishard :)"

"@_JamesMGreene: @paul_irish @slicknet @Hixie Agreed, adding script
dependency management in HTML would be complicated, messy, and verbose."

Me: what they said.

More information about the whatwg mailing list