[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.
-Boris
More information about the whatwg
mailing list