[whatwg] Script preloading

Wed Jul 10 08:39:42 PDT 2013

> The IE4-10 technique is invisible to pre-parsers, if we're chasing performance here it's not good enough.
> ...
> Also invisible to preloaders.

I personally don't care about scripts being discoverable by pre-parsers. I have done testing and am not convinced that something appearing earlier (in markup) leads to better performance than allowing my script loading logic to load things when I want, and just relying on the browser to do that as quickly as possible.

For instance, I've added like <link rel=prefetch> annotations for my scripts into the head of my document, and then done my normal script-based script loading as usual, and benchmarked if them being in the markup somehow magically sped up the page. I saw no appreciable increase in average page load speed in my testing.

It's quite possible that this is because when I use script loading, generally speaking, I'm only loading the scripts I consider to be most critical for actual page load (not everything and the kitchen sink), so my script-based script loading during page-load usually is pretty darn quick. I "defer" the rest of my code that's not as critical until later (perhaps until when needed, strictly), which is something that markup alone doesn't let me do.

I like the fact that I can have my bootstrapper "load.js" file either at the very top (and thus it starts loading them nearly immediately) if the scripts I want to load are more important than the images and stylesheets in the markup, OR I can put my load.js file at the bottom of the markup and thus give a chance for other content to start loading slightly before my scripts start loading.

The fact that browsers are trying to second guess developers and look-ahead to find and prioritize certain resources is NOT something I consider a positive benefit that I'm eager to assist. I still come from a world where a developer ought to get to decide what's higher priority.

There's certainly a strong pre-disposition among a lot of developers to falling in love with declarative markup-only solutions. I share no such obsession, when it comes to script loading. I think script loading is far more complex than markup is ever going to be equipped to handle.

To be clear, I will not be satisfied with a markup-only approach. No matter how complex it is, it does not handle all the use-cases I care about. I feel like a broken record on these threads, because I keep talking about why markup-only is insufficient, and people keep trying to convince me they can make markup more and more complex and certainly they'll eventually convince me that markup-only is superior. The more complex you make the markup-only proposals, the more I'm convinced (and self-validated) that markup is the wrong tool for the complex use-cases I care about.

-----------

All that having been said, I am not trying to block a solution that would BOTH serve those who have a subset of (simpler) use-cases which are markup-centric, and those of us who care about serving more complex use-cases via code. A solution that both camps can accept is better than either camp being happy to the exclusion of the other.

I would be fine if we went with a variation of Nicholas' proposal. Let me state that new proposal here:

******************************
Summary:

1. `preload` attribute on <script> tags in markup, `preload` property on script elements created by code. In either case, its presence tells the browser not to execute the script once it finishes loading.

2. `onpreload` event fired on any script which has `preload` attribute or property on it at the time its (pre)loading finishes (and execution is thus suppressed). Otherwise, not fired.

3. To "execute" a script that was preloaded in code, remove the `preload` attribute or property from the element, which signals to the browser that it's OK to execute it now. If you remove it before loading finishes, the browser acts as if it was never marked as "preload" and continues as normal. If you remove it after preloading finishes, the browser is free to execute that script ASAP now.

4. If you are doing markup-only loading, you signal to a "preloaded" script that its eligible for execution by putting a matching selector to it into a `fulfills` attribute on another script element. If a script finishes loading and it's already been signaled by another `fulfills`, it will run right away. Otherwise, it'll wait until some script executes that has a matching `fulfills` attribute on it.

Details:

The behavior of preload-but-don't-execute is controlled by the markup presence of a `preload` attribute on script tags (thus discoverable by pre-parsers), or a corresponding `preload` property in the script-based loading scenario. BOTH sides of the feature have to be implemented -- markup only is NOT enough for my needs.

That attribute/property being present/set would be the only thing that signals to the browser "load this script, but DON'T auto-execute it until told to do so".

There would need to be an `onpreload` event which would fire for the script-based loading logic to catch and use.

It continues to be wrongly asserted that the current `onload` event on scripts is sufficient. It is not. It's a chicken-and-the-egg, because `onload` is fired strictly when scripts have loaded AND executed. We need an event to tell us when it's ONLY loaded but strictly HASN'T executed yet, which makes `onload` insufficient. And no, we can't change the semantics of `onload` -- far too much legacy content relies on the confusing semantic that "load" means "loaded and executed" -- that ship sailed long ago.

----

It's quite clear and obvious how the `onpreload` event is useful to script-based loading. But we still need a way from code to signal to a script element that it's ok to go ahead and execute. I could invent several different ways of making that happen. Here's one:

If you remove the `preload` property (using `delete` or setting to `undefined` or whatever) on a script element, that signals to the browser "this script is ok to execute now". If you remove the `preload` property BEFORE the script has finished loading, then that script will behave just like it was never marked for preloading. If you remove the `preload` property AFTER it's finished preloading, then the browser knows it's ok to execute that script now.

From a script-loading/loader perspective, this system is quite simple (compared to some of the other suggestions). As a script loader, I load all the scripts as `preload`, and a listen for the `onpreload` event on each of them. When each event fires, I consult the "dependency chain" that I'm aware of because of how the developer used the loader API, and I either execute the script right away, or I wait and execute it after I execute others.

NOTE: this even lets me serve the use-case where I speculatively load 2 or 3 scripts, but I'm not sure if I'll use all of them or not. I'm not implicitly giving control of the execution over to some other automatic mechanism (like by tieing it to another script). I'm simply saying "preload this one now, I'll decide later if I need to use him or not. Thanks."

This mechanism gives the script-based loading 100% control of any and all script loading use-cases. No matter how complex the dependency chain may be, it can always be expressed by this system. That's a huge win from my perspective.

----

But what about markup-only advocates? How will they take advantage of `preload` attribute? Specifically, how will they, in markup-only, indicate when they want a preloaded script to be eligible for execution.

I'm not a markup-only guy, as I've said, but I'll invent one possible simple solution for the markup-only folks:

<script id="my-script-1" src="1.js" preload>
   <!-- 1.js preloads but doesn't execute, yet -->

<script class="my-cool-scripts" src="2.js" preload>
   <!-- 2.js preloads but doesn't execute, yet -->

<script id="cool-script-3" src="3.js" fulfills="#my-script-1, .my-cool-scripts" preload>
   <!--
   3.js preloads but doesn't execute, yet.
   whenever it DOES execute, `fulfills` will signal that any selector-matching
   script elements are now eligible for execution as well, as soon as they are ready.
   -->

<script src="4.js" fulfills="#cool-script-3">
   <!--
   4.js loads as normal. then, AFTER it executes, it signals to #cool-script-3
   that it's fine for it to execute now, as soon as it's ready.
   -->

Notice that I've intentionally inverted the previously suggested markup-only paradigm. Instead of marking a script as "depending on" some other script, I'm marking a script as "fulfilling" the dependency for another preloaded script (or scripts). Why? Because it leads (in many cases) to less markup.

Imagine this scenario: I load jquery.js and 4 other plugins. I could either mark the 4 plugin script tags with "depends on jquery", or I could mark the one jquery element as "fullfills these 4 plugins". The latter is simpler because it requires less markup in general.

Does this markup-only solution fulfill 100% of script loading cases? No, not even close. But IMO it fulfills enough of them (certainly more than <script> currently does) that it is as much markup complication as we should invent, and should make most markup-only advocates happy most of the time.

I don't think we need to make markup more and more complex to handle all the possible scenarios. I think at some point, when you want really complex loading capability, you have to cross over into script-based loading.

----

But, if you REALLY want to invent complex markup and keep chasing down all the various use-cases, be my guest. As long as you give me the simple script-based mechanism I described above, I ultimately don't care what the markup-only folks come up with.

******************************

> Given the above, is there a usecase that isn't catered for by "dependencies" and existing preloading features?

Yeah, consider this scenario: I want to preload "1.js" and "2.js", but I'm not sure right now if I'll execute "1.js", or "2.js", or both. The user behavior will determine that. For instance, if they select tab #2 in my tab set, I'll go ahead and execute "1.js", and if they scroll way down on my page, I'll execute "2.js".

The conditions under which a preloaded script gets executed cannot be tied ONLY to the loading of some other script. There has to be a way to tell a script "just preload now, I'll let you know when it's time to execute, if ever." If we don't have a good script-based solution for that (no, markup alone is not enough), then it fails my needs.

> Sorry to keep being Mr Use-case, but what do you need to do that isn't catered for? You can call markNeeded() when you want the script executed & both a promise and the script's "load" event will tell you when it's done. Why would you need to know when it's downloaded but not executed?

No, as stated above, the `onload` event will NOT tell me when it's only loaded but not executed. `onload` only fires after execution. Chicken-and-the-egg.

Where would this promise come from that I could listen to (instead of listening for an event)? Would the creation of a script element (`document.createElement("script")`) give me the promise? Would the setting of `whenneeded` property on the script element return me a promise?

> Can you provide a comparison that shows another suggestion to be simpler than both of Hixie's proposals and match/beat it's performance?

Those are not the only (or even primary) concerns from where I sit. We don't just need "another mechanism". We need, finally, a mechanism that lets a script loader handle 100% of whatever niche or complex use-cases it might be presented with.

Most of the solutions proposed fall short in some way or another. For instance, it's impractical that a script loader could come up with unique ID's or class-names (for the `dependencies` or `fullfills` ideas) on dynamically generated script elements, because of the undue burden of searching the current DOM to make sure what you generate doesn't already exist (or the CMS case, for instance).

I have provided a proposal above which serves what I want from script-based loading (serves 100% of my needs). I've also suggested a fairly simple markup approach, but since I don't care that much about markup-only approaches, you can make that as arbitrarily complex as you want, as long as you also let me have script-based loading the way I need. I think that's a fair compromise.

--Kyle