To break it down, there’s a couple key areas:
- Browser – This represents objects like ‘window’, ‘window.location’, and the like. Improvements here also indirectly affect rendering performance.
- DOM and CSS – These are the object representations of the site’s HTML and CSS. When creating a web application everything will have to pass through these representations. Improving the performance of the DOM will affect how quickly rendering changes can propagate.
- Parsing – This is the process of reading, analyzing, and converting HTML, CSS, XML, etc. into their native object models. Improvements in speed can affect the load time of a page (with the initial creation of the page’s contents).
- Rendering – The final painting of the page (or any subsequent updates). This is the final bottleneck for the performance of interactive applications.
Dean Edwards (February 28, 2008 at 4:29 am)
Firefox really sucks for rendering speed. What’s with that?
Sean Hogan (February 28, 2008 at 5:06 am)
m0n5t3r (February 28, 2008 at 6:08 am)
@dean: Firefox 3 has improved the rendering speed a lot; I am currently working on a web interface for a product, and it involves lots of drag and drop, and the difference between FF2 and FF3b3 is staggering. That being said, the new Yahoo mail interface still moves like crap, so a fast browser can’t help bad code too much :D
Dig (February 28, 2008 at 9:32 am)
Yeah. I noticed that while FF3 is apparently beating out Kestrel in SunSpider, Kestrel still destroys everyone on the tests they linked to at:
Most of those tests are really really DOM intensive though, requiring hundreds to thousands of DOM nodes to be created and changed simultaneously. I don’t know how realistic that is for the real world, but FF’s speed in the DOM doesn’t seem improved much this release (probably why most of the tXUL performance bugs for FF3 seemed focused on extra removing DOM too).
h3 (February 28, 2008 at 10:47 am)
Yeah .. and with firebug installed it almost revives old dialup memories *sigh*
Have you tried Epiphany ? It’s the gecko engine too but the speed is really not comparable, I always wondered why..
And yes it’s really improved in FF3 :)
Tom (February 28, 2008 at 11:41 am)
That said, I understand that all the layers matter. CSS and layout (especially dynamic) are intensive beasts.
Brendan Eich (February 28, 2008 at 12:59 pm)
Any big difference in core JS performance between the SpiderMonkey js shell and a browser embedding of SpiderMonkey is (IMHO) a bug to fix. We are monitoring the delta and driving it to zero.
pd (February 29, 2008 at 8:38 am)
The headline for this post might as well be “Passing the buck: JS is not slow, Gecko’s DOM and CSS is the bottleneck”.
To the end user, they don’t care.
To the developer who writes a bit of JS and has very little control over performance (cannot set memory usage – even if we wanted to – poor access to perf testing tools) doesn’t care if it’s JS or DOM or CSS either! Essentially they are all the same thing as JS manipulates DOM and CSS to actually achieve anything.
I’m not sure really what the point of this article is. John are you do some expectation management in that you are trying to ensure people don’t expect mind-blowing perf improvments from JS improvements? Are you trying to ensure focus on perf continues beyond any JS perf improvments?
pd (February 29, 2008 at 8:41 am)
hmm, I wish I saw Brendan’s comment before I wrote mine (page was cached). That’s all that needs to be said Brendan. Thanks for saying that as it makes me feel better at least :)
Julien Huang (February 29, 2008 at 7:42 pm)
Nothing to do, but what soft did you used to make the diagram ?
PS: congratulations for this wonderful tool that’s jQuery, it’s certainly the most intuitive & fluent lib that I have ever used.