W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2011

[whatwg] Proposal for separating script downloads and execution

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Wed, 09 Feb 2011 10:51:52 -0500
Message-ID: <4D52B818.9030804@mit.edu>
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.

Received on Wednesday, 9 February 2011 07:51:52 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:30 UTC