4 ms·

DOM Monster: JavaScript performance bookmarklet

74 points by mickeyben 16y ago

MartinMond 16y ago
I watched javascriptmasterclass.com and got the DOM Monster early. I use it quite often. It's like YSlow only with lots more and more specific tests.
pierrefar 16y ago
Not surprised that Techcrunch, RWW, and the NY Times are getting bad scores. They're the proximate reason I started using noscript. Sadly also php.net can improve. I checked a few function reference pages and they had >6000 elements each. Ouch.
chime 16y ago
They need to improve the suggestions: > Reduce the amount of <iframe> tags. There are 1 iframe elements on the page. 1 iframe isn't bad. This shouldn't even be worthy of a tip. > Reduce the amount of tags that use the style attribute, replacing it with external CSS definitions. There are 1 nodes that use the style attribute. 1 style isn't bad either. They use it on their own page. > Found 116 <script> tags on page. Try to reduce the amount of script tags. This shouldn't be just a normal warn. 100+ script tags should be a major warning. > Nesting depth is very high. Some of the nodes are nested more than 15 levels deep (these are marked with a dashed red border). > Nesting depth is a little high. Reducing it might increase performance. Both of these are shown on HN. Only one should be shown. > Some nodes use transparency. To improve rendering performance, try not to use the CSS opacity property (found 2 nodes, marked with a dashed blue border). It would be awesome if it could highlight these nodes somehow. Actually, would be awesome if it could highlight all visibile nodes that match any warning/tip. They already do that with nodes at 15+ nesting depth.
- gruseom 16y ago
  Reduce the amount of tags that use the style attribute, replacing it with external CSS definitions. Is this supposed to be for performance or are they just suggesting "good practices"? If it's performance, I'd like to see some evidence that style attributes slow down the DOM. I don't know of any, and it would be significant.
- btipling 16y ago
  >This shouldn't be just a normal warn. 100+ script tags should be a major warning. How do you think JSONP works? Why is this bad?
  - kwamenum86 16y ago
    The bookmarklet might assume they were there on initial load.
- madrobby 16y ago
  You're welcome to fork & change - we'll gladly merge good suggestions in!
rouli 16y ago
This tool was created two years ago (http://ajaxian.com/archives/javascript-performance-rocks-beware-the-dom-monster http://ajaxian.com/archives/javascript-performance-rocks-bew...). I guess the big news now is that it's been open sourced and made available for free. Were there any updates on the rule set in use?
btipling 16y ago
This is basically advising you to create small pure HTML pages without any JavaScript circa 1995. Just try it on Google Documents, the whole screen turns red. Deeply nested HTML Elements, lots of DOM elements are problematic? I guess we shouldn't make fancy web pages, full desktop apps in the browser as browsers can't handle it. ^_
- ahoyhere 16y ago
  Not true at all. I design heavily interactive apps and my husband, Thomas, wrote the first OSS JavaScript animation library (Scriptaculous). We consistently push boundaries. It's what we do :) But for a good example of how to do heavily interactive, shiny, Javascripty apps, look at our work on http://twistori.com http://twistori.com http://letsfreckle.com http://letsfreckle.com http://pepsicozeitgeist.com http://pepsicozeitgeist.com etc :) not to mention Scriptaculous, Scripty2, Zepto, etc. And test their performance versus others. Yep, making heavily interactive, heavy graphical web apps is a trade-off. That's why you have to know every single little thing that can slow things down, and then you have to make the decision which you can get away with and which you can't. Thus our suggestions are quite strict! For more information, you might enjoy our book: http://jsrocks.com http://jsrocks.com :)
  - btipling 16y ago
    Well what do you think would score better given your tool, a page with basic HTML or google docs? Ok that's not a fair question, but the problem is with the suggestions, it suggests you to move toward a blank page. With nothing on it. With the exception of maybe letsfreckle, those apps you mentioned are shiny and have some dynamicism, but they are not heavy client side apps. I can't see how letsfreckle performs on your tool given it has a paywall and there's no demo. Having said that, I do want to read your book. I'll check it out.
    - ahoyhere 16y ago
      So, what you're saying is, if our tool says your web app is "fat" and to "lose weight" -- so you plan to implement that suggestion by cutting off a leg? Measurements exist for a reason. You have to use your own judgment to interpret them.
Sephr 16y ago
Why is serialized DOM size important? There is not a single circumstance where you should ever be serializing DOM to a string or parsing it from a string (innerHTML).
e-quilibre 16y ago
glad this tool is now open source
ck2 16y ago
Would be helpful to have links to a help page that explains "tips" in more detail. ie. Nesting depth is a little high Is meaningless to me - where on the page? How often? How significant of a performance hit? Oh wait, is the idea to sell books to explain this? https://docs.google.com/gview?url=http://javascriptrocks.com/performance/JavaScript_Performance_Rocks_Samples.pdf https://docs.google.com/gview?url=http://javascriptrocks.com... Okay I guess I understand.

74 points by mickeyben 16y ago

I watched javascriptmasterclass.com and got the DOM Monster early. I use it quite often. It's like YSlow only with lots more and more specific tests.

pierrefar 16y ago

Not surprised that Techcrunch, RWW, and the NY Times are getting bad scores. They're the proximate reason I started using noscript. Sadly also php.net can improve. I checked a few function reference pages and they had >6000 elements each. Ouch.

chime 16y ago

They need to improve the suggestions: > Reduce the amount of <iframe> tags. There are 1 iframe elements on the page. 1 iframe isn't bad. This shouldn't even be worthy of a tip. > Reduce the amount of tags that use the style attribute, replacing it with external CSS definitions. There are 1 nodes that use the style attribute. 1 style isn't bad either. They use it on their own page. > Found 116 <script> tags on page. Try to reduce the amount of script tags. This shouldn't be just a normal warn. 100+ script tags should be a major warning. > Nesting depth is very high. Some of the nodes are nested more than 15 levels deep (these are marked with a dashed red border). > Nesting depth is a little high. Reducing it might increase performance. Both of these are shown on HN. Only one should be shown. > Some nodes use transparency. To improve rendering performance, try not to use the CSS opacity property (found 2 nodes, marked with a dashed blue border). It would be awesome if it could highlight these nodes somehow. Actually, would be awesome if it could highlight all visibile nodes that match any warning/tip. They already do that with nodes at 15+ nesting depth.

gruseom 16y ago
Reduce the amount of tags that use the style attribute, replacing it with external CSS definitions. Is this supposed to be for performance or are they just suggesting "good practices"? If it's performance, I'd like to see some evidence that style attributes slow down the DOM. I don't know of any, and it would be significant.
btipling 16y ago
>This shouldn't be just a normal warn. 100+ script tags should be a major warning. How do you think JSONP works? Why is this bad?
- kwamenum86 16y ago
  The bookmarklet might assume they were there on initial load.
madrobby 16y ago
You're welcome to fork & change - we'll gladly merge good suggestions in!

rouli 16y ago

This tool was created two years ago (http://ajaxian.com/archives/javascript-performance-rocks-beware-the-dom-monster http://ajaxian.com/archives/javascript-performance-rocks-bew...). I guess the big news now is that it's been open sourced and made available for free. Were there any updates on the rule set in use?

btipling 16y ago

This is basically advising you to create small pure HTML pages without any JavaScript circa 1995. Just try it on Google Documents, the whole screen turns red. Deeply nested HTML Elements, lots of DOM elements are problematic? I guess we shouldn't make fancy web pages, full desktop apps in the browser as browsers can't handle it. ^_

ahoyhere 16y ago
Not true at all. I design heavily interactive apps and my husband, Thomas, wrote the first OSS JavaScript animation library (Scriptaculous). We consistently push boundaries. It's what we do :) But for a good example of how to do heavily interactive, shiny, Javascripty apps, look at our work on http://twistori.com http://twistori.com http://letsfreckle.com http://letsfreckle.com http://pepsicozeitgeist.com http://pepsicozeitgeist.com etc :) not to mention Scriptaculous, Scripty2, Zepto, etc. And test their performance versus others. Yep, making heavily interactive, heavy graphical web apps is a trade-off. That's why you have to know every single little thing that can slow things down, and then you have to make the decision which you can get away with and which you can't. Thus our suggestions are quite strict! For more information, you might enjoy our book: http://jsrocks.com http://jsrocks.com :)
- btipling 16y ago
  Well what do you think would score better given your tool, a page with basic HTML or google docs? Ok that's not a fair question, but the problem is with the suggestions, it suggests you to move toward a blank page. With nothing on it. With the exception of maybe letsfreckle, those apps you mentioned are shiny and have some dynamicism, but they are not heavy client side apps. I can't see how letsfreckle performs on your tool given it has a paywall and there's no demo. Having said that, I do want to read your book. I'll check it out.
  - ahoyhere 16y ago
    So, what you're saying is, if our tool says your web app is "fat" and to "lose weight" -- so you plan to implement that suggestion by cutting off a leg? Measurements exist for a reason. You have to use your own judgment to interpret them.

Sephr 16y ago

Why is serialized DOM size important? There is not a single circumstance where you should ever be serializing DOM to a string or parsing it from a string (innerHTML).

e-quilibre 16y ago

glad this tool is now open source

ck2 16y ago

Would be helpful to have links to a help page that explains "tips" in more detail. ie. Nesting depth is a little high Is meaningless to me - where on the page? How often? How significant of a performance hit? Oh wait, is the idea to sell books to explain this? https://docs.google.com/gview?url=http://javascriptrocks.com/performance/JavaScript_Performance_Rocks_Samples.pdf https://docs.google.com/gview?url=http://javascriptrocks.com... Okay I guess I understand.