Posts from Monday, September 13th, 2004

Things That Go Beep In The Night

Published 19 years, 6 months past

A couple of nights ago, Kat and I watched most of Toy Story 2 before going to bed.  In subsequent nights, we watched the rest of the movie, and also the original Toy Story, but that’s not important right now.  It was interesting to compare the technical differences between the two, from rendering to animation, but that’s also not important right now.

A few minutes before 5:00am on the morning after we’d watched most of TS2, we were awakened by a cry from Carolyn.  She settled back down within a minute, and as we lay there dropping back off to sleep ourselves, we very clearly heard, coming from somewhere in the house, a quick series of three beeps.

My first thought was the carbon monoxide detector, but it wasn’t loud enough or the right tone pattern (the CO detector just wails in one long earsplitting tone).  My second thought was a fire detector running low on batteries, but again, wrong tone pattern.  The interval between these two thoughts was probably a couple of minutes, because it was very early in the morning and I was stumbling around the house trying to figure out what had produced the sound.

After a tour of the first floor and a quick peek into Carolyn’s room, I went back to bed.  It took a while, since I’d shifted into sentry mode, but I eventually fell back asleep.  We haven’t heard any mysterious beeps since then.

It’s hard to shake the suspicion that our electronic gadgets have started talking to each other at night.  I’m not sure what they’d talk about; how much would a VCR really have to say to a cell phone?  Maybe they discuss difficult philosophcal questions and further illuminate the nature of existence.  Maybe our technosphere has gotten sophisticated enough that a collective awareness has emerged.  If that’s true, then it’s little wonder we wouldn’t have heard about it.  What interest would a global intelligence have in talking to any of us?

Then again, maybe a short-circuit or other unexpected condition triggered some beeps, and that was that.


Standards Savings

Published 19 years, 6 months past

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.


Browse the Archive