Why Web Standards Matter (Case Study)

Project managers often have a hard time understanding web standards and why they matter. In this case, my arguments made a perfect business case for the managers of a particular project.

Recently I was called out to debug some javascript code that did not perform. There was really not a big problem in Firefox, but Internet Explorer hung using 20 seconds or more each time the script was activated by the user.

It was one of those applications where you click on a little plus to expand a list of units in a subgroup. The list that caused the trouble contained 1,416 rows.

The subgroup was invisible and already rendered. On click a display style property changed from display:none to display:block. Unfolding the list took 19 seconds in IE. WHAT?

A first look

A brief investigation hinted something was wrong:

  • Content/markup ratio: 23%/77%
  • Page contained 27,000 elements in the DOM
  • W3C HTML Validator unable to validate
  • Firefox HTML validator gave 6 HTML errors and 15,700 warnings
  • No JavaScript errors, though

There were plenty of transparent spacer gifs, and the spacer gifs were used in empty table cells. A brief count in the DOM revealed that 5,400 of the 7,200 images were transparent gifs. Uh oh.

Most important pitfall: TOO many elements in DOM

JavaScript really was not the problem here, because there was nothing but an innocent display:block statement. The problem had to be rendering related and I got suspicious as the hidden list contained:

  • One giant table element with display:none
  • Inside that 1,416 rows
  • Each of the rows had a table cell with one new table inside it.
  • Each nested table had 15 cells (four of which contained only transparent spacer.gifs)
  • Tables nested six levels deep on the page

All this equals bloated HTML and 27,000 total HTML elements on the page. Here’s how we got down to 11,000 elements without removing any content:

Strategy for reducing element count

These were my recommendations for reducing element count and thereby improving performance:

Avoid JavaScript. We found that in this situation, the javascript performance had big variations on different browsers (and on the same browser, with different people logged in). In this case, we were able to avoid JavaScript, which is not always the case.

Remove validation errors and warnings. Browsers are coded after the HTML specifications, HTML specifications tell browser vendors how their code should interpret valid HTML. If the code is not valid, sometimes browsers guess what they think the source code means. The only thing specified in the HTML standard is how valid code behaves. Invalid code is left for the browser to do whatever it pleases. If, for instance, a form element is nested directly in a table element, it’s not allowed. But what will the browser do about it? Render the element? Or silently ignore it? Can you submit forms at all from the page? If your form cannot submit, it can be a big risk to use HTML that does not validate.

In this particular case, there were 6 errors and 15,700 warnings (all of which could be easily fixed).

Remove elements without content. Originally each of the 1416 rows had its own table element. Additionally, a lot of transparent images were placed in empty table cells. All of this clutter was removed. We ended up using six table columns in the parent table, compared to originally 15 columns in each of the 1416 child tables. This really adds up when you consider that in our baseline example we had 1416 rows. All in all we reduced HTML footprint with 40%.


Before After
display:none on subgroup: 19 sec <0.5 sec
document.getElementsByTagName('*').length: 27,000 11,471
Number of image tags: 7,200 1,426
Number of tables: 1,416 11
HTML validation errors: 6 0
HTML validation warnings: 15,700 0
IE memory consumption (avg): 46MB 35MB
IE memory consumption (peak). 58MB 36MB

Long-term findings

  • Don’t use JavaScript for general page layout rendering. Think really really hard if it can be done without JavaScript. One example: Print should be done with CSS
  • If there is no way around it, use standard JavaScript libraries were browser bugs, etc are hidden for the programmer
  • Tables used for layout are evil. Use tables for table-based content ONLY
  • HTML code is really messy and hard to maintain. Should be cleaned up to avoid similar situations in the future. Clean up nested tables, table cells with transparent gifs. Use CSS where appropriate could shave up to 50-70% of HTML footprint
  • Many HTML validation errors. Code improperly nested, forgotten end-tags: Ideally, the pages should have no validation errors. It’s an achievable work worth the effort and very educational way of working with the code

Long-term benefits

In general, several benefits could be gained by raising the knowledge of HTML, CSS, Javascript, web standards, and browser issues.

  • Include easier maintenance
  • Lower risk of change
  • Lower risk of browser incompatibilities
  • Lower risk of browser crashes

Browser tools

These tools I used for quick investigation of the HTML page:

More info on my firefox extensions in the article: Web developer’s collection of browser tools (Nov 30th, 2005).

Technorati Tags: , , , , , , , , ,

9 Responses to “Why Web Standards Matter (Case Study)”

  1. » Technikwürze #28 — cne _LOG Archiv Says:

    […] Jesper Rønn-Jensen: Why Web Standards Matter (Case Study) […]

  2. Technikwürze - Design & Webstandards Podcast » Blog Archiv » Technikwürze 28 - Surfen mit Candice besser? Says:

    […] Jesper Rønn-Jensen: Why Web Standards Matter […]

  3. Mal Ross Says:

    When I saw this topic’s title, I was really looking forward to finding out once and for all why web standards matter. Alas, I really can’t see what this case study has to do with web standards. It sounds as though the page could quite easily have been modified to continue to use tables AND adhere to web standards without having any positive impact on the performance.

    The mere adherence to web standards does nothing to guarantee performance improvements. If you’d called the post “Why writing minimal markup matters,” then I’d say you’ve got a point. Please do point out why I’m wrong – I want to learn this stuff, but I’m struggling right now.

    Thanks. :)

  4. Jesper Rønn-Jensen Says:

    Mal. Thanks for your comment. I think you have an important point here.
    And let me add that “Why writing minimal markup matters” is a brilliant headline. Wish I had thought of that when I wrote this!

    However, I still see that web standards play an important role, especially in this particular case study. It’s true that we could follow standards AND still use tables and still have the performance issues.

    But the point I’m trying to make is that web standards is the right place to start, if you experience rendering problems like we had. Standards define how browsers should work. If you use non-standards code, the browser vendors for themselves decise how things will work (and that can easily lead to rendering bugs and differences on different browsers)

    With 10,000 different browser versions already existing today, I think the alternative is hard to manage: I have no chance in life to know all the browser oddities and behaviours if I for example put a <form> element directly inside a <table> element. Some browsers may neglect to know about the form? I don’t know, because browser vendors can decide for themselves how they want it to work. It’s unspecified.

    In this particular case, we had 15,706 errors and warnings, and it was likely that some of them had an influence on the rendering engine that caused the bug we were chasing.

    In my opinion, Web standards are the first step to code that’s cleaner, better, slimmer, performs better, less susceptible to browser bugs. In your own words: Minimal markup.

    One more reason why I start with webstandards: If you run into browser bugs, they’re usually corrected with newer versions of the browsers. (I’ve previously reported about a bug in IE and another one in Firefox).

    Browsers are coded today with the purpose to support the web standards (no exception!). So if non-standard code works in browsers now, it may stop working the way you intended in later browser versions.

    Also the case I’m describing here is what worked for us, and starting with eliminating the 15,706 errors and warnings was fairly easy. Besides from the performance issue, we got several further advantages, as I described in the article. Decide for yourself what works for you.

  5. penk - Keep on rockin’ in the free world » Blog Archive » 本日書籤 Says:

    […] http://justaddwater.dk/2006/06/29/webstandards-case-study/ […]

  6. justaddwater.dk | Toolbox — locating problems in HTML Says:

    […] I decided to make a little toolbox that’s easy to apply on web pages, when investigating problems with web pages. Basically, it’s the tools I used when investigating the case I described in “Why web standards matter (case study)” […]

  7. justaddwater.dk | Technique — locating problems in HTML Says:

    […] The instance that sparked this is a particular case I described earlier in “Why web standards matter (case study)“, in which I used the following tools and investigation techniques. […]

  8. chad lindstrom’s blog » Blog Archive » Inconsistent Interpretation with Web Development Best Practices Says:

    […] Why Web Standards Matter (Case Study) […]