- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Wed, 09 Feb 2011 10:51:52 -0500
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
Received on Wednesday, 9 February 2011 07:51:52 UTC