[whatwg] Proposal for separating script downloads and execution
getify at gmail.com
Wed Feb 9 07:37:04 PST 2011
?>> Regardless, considering such things is way outside the scope of anything
>> that's going to be useful for web developers in the near-term dealing
>> with these use-cases.
> Yes, but so is the proposal here, no?
No, I don't think so. A huge part of my point with the proposal is that it
builds on existing spec wording AND it has browser implementation precedent
from IE, and *some* stated support from Opera. That makes a "solution" a bit
more tangible and foreseeable in the near future, as opposed to for instance
they take more advantage of multi-threading -- a task which could be years
> Yes, but what makes you think that those very same sites will make good
> use of the functionality we're proposing here?
Fair enough, the offenders will probably keep on offending. EXCEPT that web
performance advocates like myself (and Steve Souders, and many others) will
have something tangible to take to them in performance evangelism efforts.
Right now, if we try to get them to address their bad performance, it
involves suggesting an extremely complex and convoluted set of brittle
hacks, which they are rightly hesitant to consider.
It's a much easier "sell" if we can say "look, here's this simple mechanism
dedicated specifically to helping the problem your site has, would you
> Neither will the browser eagerly parsing. ;)
>> What's VERY important to note: (perhaps) the most critical part of
>> user-experience satisfaction in web page interaction is the *initial*
>> page-load experience.
> Really? The pages I hate the most are the ones that make every single
> damn action slow. I have had no real pageload issues (admittedly, on
> "desktop") in a good long while, but pages that freeze up for a while
> doing sync XHR or computing digits of pi or whatever when you just try to
> use their menus are all over the place....
There's lots and lots of research into how user-satisfaction in web pages
and web applications is more driven by the initial page-load experience than
any other factor (not exclusively, just majority). Again, I refer you to the
great work Steve Souders has done in this area. There's plenty of
information about how when sites speed up their page-load (and nothing
else), user retention (and a whole related host of other positive
user-satisfaction indicators) all go up, sometimes dramatically.
>> So if it's a tradeoff where I can get my page-load
>> to go much quicker on a mobile device (and get some useful content in
>> front of them quickly) in exchange for some lag later in the lifetime of
>> the page, that's a choice I (and many other devs) are likely to want to
> See, as a user that seems like the wrong tradeoff to me if done to the
> degree I see people doing it.
We can debate that point forever and never really come to a definitive
consensus. I myself sometimes feel like this technique can be taken
overboard and I'm not entirely behind all attempts to defer script
execution. But nonetheless, there's provable validity to making some
tradeoffs like that, and seeing user happiness go up. We're simply asking
for the means to make those tradeoffs without costly/ugly hacks. That's all.
There's obviously an "art" here in balance. But the numbers clearly indicate
that addressing page-load performance bottlenecks leads to huge gains in
> Perhaps they just have different goals? For example, completely
> hypothetically, the browser may have a goal of never taking more than 50ms
> to respond to a user action. This is clearly a non-goal for web authors,
In fact, no. As I asserted in an earlier message in the thread, I believe
the goals of the browsers (to be faster in page load) line up well with the
goals of web authors (to reduce the amount of bounce traffic because of slow
loading sites, especially on mobile).
Not all web authors care about performance (often they just care about bells
& whistles). But there's a recent undeniable trend, and huge uptick, toward
more awareness of web performance optimization issues and specifically on
improving initial page-load experience.
Consider the Google algorithm change where they take page-load speed as a
factor in ranking. Clearly, more and more web authors (and the businesses
that drive their decision making) are seeing the benefits of
performance-savvy websites, so I believe we'll see even more alignment of
goals as we move forward.
> Should a browser be prohibited from pursuing that goal even if it makes
> some particular sites somewhat slower to load initially (which is a big
> "if", btw).
A browser should have some strong warnings against acting in a way that is
counter to the expressed intent of a web author. If a web author is taking
steps to more actively control the pipeline of resource loading and
page-load performance, the browser should not try to second-guess that
author and thwart their efforts.
Again, this should be a cooperative thing, not an adversarial tug-of-war.
> I think you're assuming a uniformity to browser implementations that's
> simply not there.
No, I'm relying on the growing trend of more and more web authors being:
1) aware of performance issues, especially initial page-load performance
2) able to use more tools to measure these issues, and test them across a
broader range of user-agents
3) able to leverage more functionality that the spec and browsers give to
them, to have better optimization of their pages
>> As for telling if the browser were deferring parsing to a useful degree,
>> I'm sure that the only way to actually determine that would be test a
>> site with a particularly long script file (length being a rough
>> approximation for parsing time), and see just when (between load and
>> execution) the big parsing delay (as observed previously) was happening.
> Assuming the browser does the parsing on the main thread, yes? What if it
Regardless of what thread the processing is on, if the parsing happens
during the critical few moments of page-load, and the device's CPU/hardware
is overwhelmed, it's going to be obvious that there's a slowdown or freeze.
> I can live with that.
>> Do you see how what I'm asking for is not direct forcible control over
>> parsing but some way to strongly encourage the browser to defer both
>> parsing and execution until later, when *I* say I want it to?
> That wasn't what the initial proposal sounded like, but ok. If that's
> what you're looking for, that sounds fine.
I'm glad we can see some hope of finding agreements. :)
The major problem in the mobile-performance part of the use-case is around
parsing. Noone is suggesting here that the web author should have a .parse()
function where they deterministically control it and handcuff the browser.
What we're suggesting is that we be able to directly control execution, and
in so doing, make an indirect hint to the browser that it should also
strongly consider deferring the parsing. The spirit of that effort is to
have less script parsing happening during the critical moments of initial
page-load, for pages where that's an issue and for which they take steps to
address that issue.
More information about the whatwg