views:

371

answers:

6

I am a fan of valid web pages and always spend time passing new sites through the W3C validator.

When trying to make a case for why companies should validate web pages I quickly thought of accesibility and the future-proofing of the web site on more primitive devices such as phones, fridges, watches, the next-big-thing etc.

However I then wondered if there is a computational overhead involved in rendering web pages that do not validate?

Has there been any research done in this area? and do some browsers handle invalid content better than others?

+10  A: 

It's likely that an invalid page will take longer to render because the browser will need to implement some fault recovery (deductive work to find where the next valid content is and how the browser can continue rendering it) and this can introduce an overhead.

Actual difference can only be told after careful measurements and (if possible) browser source code analysis.

sharptooth
A: 

I don't think so. I think it's just about the same, maybe even more for valid pages (things like & in URLs). Especially since some browsers (ahem, IE) are practically designed for invalid pages. Not to say I like invalid HTML, though.

Lucas Jones
I've heard numbers like 70% of the rendering code in a browser is there to figure out what you actually meant to do when you give it some crap.
Alister Bulman
"Crap" may just refer to complex combinations of elements that are difficult to render correctly, not invalid code.
Jenko
+4  A: 

I suspect the cost of any fault recovery or other handling of invalid content will be rendered negligible just by the network latencies and other costs.

Brian Agnew
Valid point, but don't underestimate the size and complexity of pages - parsing and rendering them can be very resource consuming.
sharptooth
+1  A: 

I then wondered if there is a computational overhead involved in rendering web pages that do not validate?

Sure, but it's pretty much minuscule. Parsing speed in general won't have a tangible impact, compared to the much larger delays caused by network download time.

Where it can make a difference to load times is when you close a comment incorrectly. Fixups for comment problems can be delayed until the end of the page, so progressive rendering won't happen and nothing will render until the whole page is downloaded.

bobince
Is it a fact that rendering speed is not important? I know Google Chrome is lightning fast, but that may be more to do with the huge amount of JavaScript around these days?
Jon Winstanley
Rendering speed can be important. Scripting speed is important. Parsing speed, happening once per page load, is unlikely to be very noticeable except in pathologically huge files.
bobince
A: 

I'm just speculating here, because I have no reference or hard data to back this up, but I think that the rendering mode that the browser chooses can have quite some impact. Most browsers have two or three rending modes, one for standard-complient pages (which is usually triggered when you serve the browser a valid html document, but not always), and quirks mode, which simply tries to make the best of whatever you throw at it. I can imagine that the performance of standards-complient mode is a lot better than that of quirks mode, but again: just speculating here. If anyone can back this up with evidence or a good reference, feel free to comment or post a better answer!

Daan
+6  A: 

I think your stronger argument will be in maintenance. I designed the intranet for the last major company I worked for. I created page templates that have valid markup and used conditional comments to target stylesheets for different versions of IE. The site was launched 2 years ago; it looks the same in Firefox 2 & 3, Safari 2 & 3, and IE 6, 7, & 8! No markup or style changes were necessary. This means that when the organization finally updates to IE 7, the web developer team will not have to do anything. Big win in reduced maintenance costs.

Will Green