[whatwg] Proposal for separating script downloads and execution

Boris Zbarsky bzbarsky at MIT.EDU
Wed Feb 9 07:51:52 PST 2011

On 2/9/11 10:37 AM, Kyle Simpson wrote:
>> 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

Again, you're assuming that the "optimization" that needs to happen is 
that same for all browsers....

>> 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.

If the hardware is overwhelmed.  On the other hand, if it's a multicore 
chip (which is what mobile hardware is shipping with nowadays) and the 
page-load is gated on one core, there's no reason to not be parsing on 
another core...

> 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.

OK, good.

> 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.

That sounds fine to me.


More information about the whatwg mailing list