By Craig Buckler

Dissect Your HTML with DOM Monster!

By Craig Buckler

DOM Monster is a new cross-browser bookmarklet tool which analyzes your Document Object Model and other features of your HTML page. It reports valuable information about the number of elements, empty nodes, the content ratio and nesting depths. However, the most useful feature is an overall rating and a list of warnings and tips to help you optimize your code…

DOM Monster

Click this DOM Monster link to view the results for this page or drag it to your bookmarks bar to create a permanent link.

DOM Monster is the brainchild of Amy Hoy and JavaScript guru Thomas Fuchs. The bookmarklet works in all the main browsers but, although that should include Internet Explorer, it wouldn’t work for me? Firefox, Chrome, Safari and Opera all operate as expected, with the webkit browsers offering a few additional CSS3 effects.

While there are many code analyzers available, DOM Monster provides useful information I haven’t seen elsewhere. The results are reminiscent of the the YSlow add-in for Firebug but there’s more emphasis on optimizing the performance of the HTML document than analyzing network performance and file sizes.

There are some great tips such as:

  • informing you when a new version of a JavaScript library is available
  • reducing the number of script tags
  • warning that you have too many JavaScript global variables
  • reporting excessive white space
  • suggesting the removal of inline JavaScript
  • providing the content to HTML code ratio (over 50% is considered good).

DOM Monster is a handy tool which is open source and free to use. For more information, visit the DOM Monster home page or the GitHub repository.

  • Mr Sittler

    This is a great tool! I’m still a relative beginner to web dev, but this discovery feels a bit like when I discovered Firebug — both are such great resources for learning while I’m working on a site. So thanks for the great post (I actually read about it in my inbox via Tech Times).

    Good work, Sitepoint!

  • fn64

    The best part about this is that it works like charm in Mobile Safari, while Firebug does not.

  • furicane

    If you’re liking Firebug, then it might be time to move on to WebKit console along with moving on to a proper browser.

    I tried this tool, and I find it ok-ish but not for serious development since it makes some things sound as “avoid at all costs” such as inline JS or including a few css files (it advises against that, and it’s not always the case that having 1 css file or no inline JS is good).

    • You’re brave! There are a lot of Firebug fans here who consider it to be better than all the other consoles which copied it.

      One CSS file will always be more efficient than two or more. But inline JS? You never need it and it can certainly cause accessibility issues.

      • furicane

        Firebug cannot compare to WebKit console, I’m sorry :)

        It’s one thing to prefer one tool over another, which I understand. But when you start working with WebSockets, when you need your console to be more robust and to provide more info over the elements, over what’s going on with crossite requests, give you more control over code – Firebug cannot compare to WebKit console. I won’t even bother saying the vast difference between ways of working of the two, since Firebug is written in JS. I am not trying to undermine Firebug, it is a great tool and it certainly opened eyes of browser developers – thumbs up, great work, but WebKit console > Firebug, no matter what anyone says. It’s a fact.

        Now, as for you saying that you _never_ need inline JS? Are you sure what you’re saying is correct?

        What if I’m working with a website (or an application) that uses AJAX (I prefer AHAH tho) to fetch only the required pieces of information and inject it into the current page, and only certain parts of injected HTML require additional functionality provided by JS .

        Say, I loaded a table that contains information about users, their origin and so on and I have jQuery buttons for:
        1) Delete
        2) Activate / Deactivate
        3) View Info in jQuery dialog.

        How would you, without inline JS, make regular checkboxes with certain selectors become jQuery buttons? It is possible, but is it optimized or even logical to do so? This is just one example that popped to my mind, I can provide more of them if needed.

        As for CSS – I disagree that optimization should go to such a level that it basically disables the person maintaining it from organizing it properly.

        I will always split my css in as many files as the logic dictates.
        Reason is – I will find relevant CSS faster than having to open a single (huge) file, and then using find to position myself at required position within the file where I’m supposed to edit or add things.

        I am all into optimization but only when it makes sense and doesn’t make my life more miserable. I think that no one will suffer over several css files being served instead of one, if it makes developers’ life easier.

      • Well, use whatever tool you prefer I suppose. I still find Firebug better, but I suspect that’s partly owing to being more familiar with it.

        As for inline JS, yes — I’m saying you never, ever need it. In your example, it’s so not much of an issue because you’re using JavaScript to load HTML content.

        However, it’s still not necessary to define multiple inline onclick handlers. It’s far more efficient to attach a single onclick handler to the table element. When that event occurs, it’ll bubble up and you can capture which element fired it, e.g. if it has a class of “delete” you can run the delete method for that row. You’re using one event to handle all onclicks, no matter how many rows are added or removed.

        With regard to CSS and JavaScript files, you should use as many as you need for development — add comments, whitespace, to-do lists or whatever is practical. However, you can combine and compress all your files at the deployment stage. It doesn’t matter whether you do that manually or automatically — you should notice a speed improvement.

      • Louis Simoneau

        Just adding to the discussion about inline JS, Craig’s right, one event handler (or whatever) is better than a bunch of inline ones. And as for content that’s added dynamically to the page, jQuery happens to provide you with a built-in way of handling that: the live() method. It allows you to attach event handlers to elements that don’t exist yet.

        And about multiple JS or CSS files, I again agree with Craig: HTTP requests for a bunch of files will have a noticeable effect on site load time, so combining and minimizing them in production is something every site should do insofar as is possible. There are server-side technologies that can do this transparently without affecting your source files, so there really is no downside.

      • furicane

        I’m not the advocate of absolute “musts”, I’ll never say you NEVER need inline JS but I will use it where it makes sense.
        If it’s only 1 page out of 100 using specific JS function, I definitely won’t load the function definition across other pages just for the sake of having all my JS in a single file.
        There’s also how the framework that you use to build your website works – it’s a broad topic.

        When it comes to jQuery live(), that method has serious implications and you almost always need to use die() before you attach event handlers. However, I find it way more complicated and bloated to have the JS for creating buttons within an external file included in every page of your site.
        You might dislike inline JS, I dislike it also but what I dislike more is the misconception that you need to include all your JS in . It is way easier for me to attach the code for creating jQuery buttons inside the page that I load dynamically rather than attaching events.

        The reason is that it’s much more maintainable, as you can immediately see what JS you use with that specific page once you go and edit that template.

        I’m not advocating for inline JS, I’m just saying that circumstances sometimes dictate methods that are frowned upon.

        As for CSS – development time and deployment time is what matters usually, not whether you optimized it so that it loads a microsecond sooner.
        Yes, it is true that there are less requests made if there is 1 CSS file opposed to 6 of them.
        But the real question is – is the speed gain justifying the time the developer has to spend to put all the css in the 1 file?
        Many things can go wrong here – the developer can be lazy, someone can interrupt, they can even forget to include a file and what not. Sum all the factors that distract someone when merging 6 files into one, editing a page where those css files are included and so on – I think it’s not worth it.
        I know these are nitpicking details, however I really don’t like “never do this” suggestions as the situation and work surroundings of different people is – different.

        For some, it might be easier to organize things in 1 js file, 1 css file, include it in 1 .php file or whatever language is being used and blast off – that’s perfect case scenario. However, you never know what people work with so saying never do inline js or never have more than 1 css file _might_ not be entirely accurate.
        That was what I was aiming at, not saying anyone is wrong or right :)

        Anyway, to conclude this – thanks for the tool suggestion Craig and keep up the good articles coming :)

  • Paul McKeown

    The tool is interesting and with some thought could become useful. Have to say that the measure “content to HTML code ratio” seems to consider graphics, video, audio, Flash, etc., to be ballast. Sometimes however they are the bulk of the content…

  • kaf

    Cool. This is an interesting tool to add to my arsenal.
    It seems to find some things absolutely evil that I think are perfectly fine, so its not perfect. But seeing as its not a browser plugin like similar tools there is no bloat associated with adding this to my bookmarks.

    Interestingly it really hates any of my pages with a google map on it. Apparently they don’t use this tool at google. Or they just ignore most of the warnings and only fix the ones they agree with like I probably will.

    • Could you give an example of what it reported which you don’t agree with?

      Remember that the tips are only general. Google Maps, for example, is a large JS application using lots of images rather than a typical web page with content.

  • Thanks, it works well with rekonq on KDE 4.6.

    It’s not a replacement for Firebug, but a very nice addition. It can alert you to some issues with your design which you may or may not want to do something about.

  • Has anyone managed to get DOM Monster working in Internet Explorer yet? It’s supposed to be fine, but it fails on IE6, 7 and 8 on my PC?

    • Chris C

      Craig, it didn’t come up in IE 7 under Vista Pro. for me.

      I also agree with your comments regarding the CSS being in one file for deployment, but possibly in separate files at development stage.
      As one could figure, it does work in Firefox, and does a great job.
      Thanks for the link to the tool!

  • goldfidget

    Well that’s a useful and nicely implemented little widget. I can see myself adding it to ma CMS front end pages for logged on users.

    “whoa, potentially huge issues 4 warnings indicate app ill-health” :P

  • cute idea, though I have to laugh at it claiming ACRONYM is deprecated…

    Normally I dump on ‘tools’ like this from orbit, but really it points out a lot of idiocy in other people’s code… and all my sites it does nothing but pointless ‘tips’ that are mostly either wrong or pointless… like it’s raging chodo for telling me to use HTML 5… and having the balls to call that an upgrade.

  • BrenFM

    Cheers again for a valuable pointer!

    Not that I really wanna open THAT can of worms again – but I’ve all but stopped using Firefox/Firebug. I’ve become a total Chrome fanboy and find the Webkit console to be pretty much all I need. DOM Monster is a great partner to this though, and in my own site I just came across a bunch of really stupid coding… thanks again, Craig!

Get the latest in Front-end, once a week, for free.