[whatwg] Proposal for separating script downloads and execution

?>> 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 
saying that all mobile device JavaScript engines must be changed so that 
they take more advantage of multi-threading -- a task which could be years 
before realized.


> 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 
consider it?"


> 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
>> make.
>
> 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 
user-satisfaction.


> 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, 
> right?

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 
> doesn't?

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.


--Kyle

Received on Wednesday, 9 February 2011 07:37:04 UTC