Size does matter

A good user experience requires responsiveness. Speed. Web pages that don’t make you wait more than a couple of seconds while they load, or even worse, load in bits and pieces and reorganize themselves in front of the user; “that’s the way these things work” isn’t good enough an excuse. Your users don’t want to know how your site works (even if your site is about how the internet works – they want to read about the problems, not experience them), they just want to get things done and move on. As Eve says in Gaiman’s Fables and reflections, “Some people have real problems with the stuff that goes on inside them … sometimes it can just kill the romance”.

Two of the culprits these days seem to be huge JavaScript and CSS files. They’re by no means the only causes, but they can cause trouble at times. Delays when loading a CSS file result in the dreaded flash of unstyled content on some browsers. Problems loading a JavaScript file… well, let’s just say it ain’t pretty. The delivery of these files can be slowed down by a number of factors. File size is one of them; a 168kb file will download considerably more slowly than a 6kb one.

This is made worse by the use of multiple JavaScript and/or CSS files. Separating functionality or styles in a sensible way is heaven-sent when it comes to maintenance, but the way the web works means that it’s a lot easier to download one largish file than several small ones. Multiple files mean that the browser must make multiple requests to the server, and each request carries a small overhead since the server has to include a certain amount of information with each response it makes. To top it off, most browsers are configured to open a limited number of connections to a server at any one time – IE8 allows up to 6 concurrent downloads on broadband, while Firefox allows 8; these connections must be shared between the JavaScript, style, images, and other embedded files. This can cause the downloads to be queued up on pages with a lot of stuff on them.

What we need, then, is a small number of reasonably sized files: how do we get to that?

Should HTML be considered as a data format?

In a short, but thought provoking post, Bertrand Le Roy asks whether HTML has evolved into a purely data carrying format, which is what, after all, it was meant to be in the first place.

Unless I missed the point totally, this is, in fact, the general direction of the XHTML strict specifications. With both appearance (via css) and behaviour (go jQuery!) being decoupled from the data, the contents of the html file represent only content, which is, in my opinion, Web Dev Nirvana. We cannot really have semantic html (as I understand it, this simply means that elements only ever describe what their content is, not what it does or looks like) until we have this separation.

In an aside, Mr. Le Roy says “and if we can ignore the huge majority of existing contents that is less than ideally written”. Thinking about it, it’s not as up-in-the-air-idealistic as it sounds. It’s true that no browser or device intended for browsing the net can afford to ignore 99% of the content out there, but we already have the tools to ignore this: Doctypes. Internet Explorer and Firefox already enforce different rendering rules based on the doctype for a page; if we had an XHTML SERIOUSLYSTRICT doctype, a reader could easily offer the basic or limited functionality to that (or even none at all) and give the really strict documents the real deal.

To cap it off; I don’t think we’re there yet, but we’ll get there eventually, especially once the beefier CSS3 selectors get more widespread support. Once we have those, we can even do away with the class attribute and specify appearance in a purely declarative way, turning our html into pure content.

We’ve already (mostly) moved on from the dark age of blink and marquee tags, but to be honest, we don’t need to remember the bad old days of nested tables and abused markup; we are still in the bad old days of nested tables etc. It is always good to see people like Mr. Le Roy keep the torch going forward.