Standards Savings
Yesterday morning, I saw via somebody’s feed (most likely either Matt or Simon) that Rakesh Pai has published a piece called “The Economics of XHTML”, in which he explores and summarizes many points in favor of moving to XHTML. As he says, XHTML and semantic HTML are basically the same thing, so when you read the article you should prepend the words “old-style” to the term HTML and “semantic HTML or” to the term XHTML. Thus, the following paragraph from his article:
HTML files are rather complex. They have so much irrelevant information, it becomes difficult to manage them. XHTML on the other hand, if well planned, will be much easier to manage in the long run due to sheer simplicity of the files.
…should be read (emphasis indicates my modifications):
Old-style HTML files are rather complex. They have so much irrelevant information, it becomes difficult to manage them. Semantic HTML or XHTML on the other hand, if well planned, will be much easier to manage in the long run due to sheer simplicity of the files.
I admit I’m reading a bit into the text, but I think my reading is supported by Rakesh’s statement about the basic equivalence of semantic HTML and XHTML.
Overall, it’s a very good summary of the business reasons to shift to standards-oriented design. It bothers me not at all that he left out a discussion of CSS in the article, since the focus was purely on the benefits to be gained from improving your markup. It’s often useful to concentrate on small pieces in detail, so that by the time you’ve looked at the various pieces you have a much better understanding of the overall picture. I would like to talk about an under-recognized aspect of his first point, which was (again, emphasis indicates an insertion on my part):
Semantic HTML or XHTML will give a definite reduction in amount of space used on the server, which translates to money saved. Large sites will also benefit from the bandwidth savings, though this might be insignificant for smaller sites.
It’s true that smaller sites probably won’t save a lot of money on bandwidth. This is especially true given that many small businesses pay a flat rate each month so long as their bandwidth is below a certain level. So sites in that range will likely not see significant reductions in expenses.
What they will see, though, is a faster site. Okay, actually, that’s what their users will see, but that’s the entire point. Suppose I said I could sell you a product that would make your Web site twice as fast as it is today. How much would that be worth? Maybe not much for a fandom site, but even for a small business trying to sell its products online and disitinguish itself from competitors, a 2x speed booster would probably be worth buying.
The thing is that you don’t have to make a purchase to get this boost (unless you decide to hire a consultant like me to help you migrate to standards-oriented design). There’s no product to buy. Along with all the other benefits Rakesh describes—accessibility, ease of maintenance, and so on—a faster Web site is part of the standards package.
How so? Far and away, the #1 factor in request-to-render time is the raw number of bytes you’re shipping to the user. If you’re sending a dialup user a 60KB page, then even assuming an uninterrupted, uncongested connection it will take about 15 seconds for the page to render, measured from the time the user requests it. If you send a 30KB page, it will take half that time.
I’m not just saying that because it sounds true: while I was at Netscape, Bob Clary and I did experiments on the effects of standards-oriented design on request-to-render time. We saw basically no speed improvement from using standards-oriented design beyond the reduction in page weight—but that was a substantial effect. Thus, the actual markup you use is basically irrelevant in this arena. The whole page could be one graphic scan of your brochure, or it could be a press release. Either way, the more bytes you send over the wire, the slower the site will seem. True, there are other considerations, like server load, network congestion, and so on. All of those factors will be eased, and speed improved, if there are fewer bytes per page request. It’s honestly that simple.
As I’ve been telling clients, this is what makes standards a big economic win: standards-oriented designs are nearly always much smaller than old-style designs. Usually they’re half the size of old-school pages, although that reduction can vary; Microsoft’s home page size dropped by about two-thirds in terms of the markup weight alone. With Microsoft’s traffic, they stand to save a boatload of money on that reduction. They also have a site that’s faster, that feels less bloated, that leaves more of a positive impression on the user. That’s an important consideration for any company, regardless of its size. It’s a consideration that’s harder to quantify than reduced costs, of course, but not one that can be ignored. As Richard Rutter shared, when Multimap went to a standards-oriented design, they didn’t see as much of a drop in bandwidth consumption as they’d expected, although there was a reduction. What they saw was a dramatic upswing in page views, which meant increased revenue for the firm; in other words, they were able to serve more customers and increase revenue while using less bandwidth than before.
That’s what they call increased efficiency, and it’s a competitive advantage in any arena.
