- Gene Steinberg's Tech Night Owl - https://www.technightowl.live/blog -

In Search of a Millisecond

To put things into perspective, don’t forget that a millisecond is a thousandth of a second. It takes 300 to 400 milliseconds for your eye to blink, and I don’t expect you can measure it on your stop watch.

Back in the 1970s, I drove a mundane-looking but innovative car, a Mazda RX2, which featured their new Wankel or rotary engine. The auto was about the size of a Toyota Corona (a predecessor to the Camry), and similarly equipped, but the Mazda was incredibly fast for a cheap compact. You could go from zero to 60 miles per hour in ten seconds flat. To show you how far things have come, today’s family car does the same thing in as little as six seconds with a conventional piston engine.

But the real change of perspective can be seen in the incredible and ongoing increase in computer processing speeds. Some years back, Steve Jobs touted the first Power Mac G4, with a 400 MHz processor, as having the power of a supercomputer. These days, your tiny iPhone 4, and competing smartphones, are closer to 1 GHz in processor speed, although I realize actual performance comparisons are extremely difficult. But imagine packing essentially the power of yesterday’s 40-pound computer into today’s portable computing device weighing less than five ounces. In a few months, the power players in this market will even be touting processors and graphics chips sporting multiple cores.

At some point, you wonder just how much computing power you need to manage your email or visit your favorite Web sites, not to mention playing music or movies on your Mac or PC. Just about any personal computer, even the ones costing a few hundred dollars, can manage these functions with decent levels of performance.

But we’re still addicted to speed, and tiny differences that are beyond your ability to detect can appear to mean a lot.

Take a recent Macworld [1] review of Google’s Chrome 8 browser. Overall, it’s rated as fastest app of this sort on the planet, the king of the hill, at least for now. But when you look at the fine details, you have to wonder whether the difference, well, makes a difference.

Take the speeds of rendering their text XHTML page, clocking in at 0.55 seconds for Safari 5.0.3, and 0.64 for Chrome 8. Remember, as I said above, that it takes from .3 to .4 seconds for your eye to blink, meaning you won’t be able to detect the difference between the two. When it comes to displaying CSS content, Safari does it in 32 milliseconds, whereas Chrome 8 is much slower, at 54 milliseconds, if you can call that slow. But where Chrome 8 leads is in JavaScript rendering, scoring 372.4 milliseconds, compared to 388.5 with Safari. That, and a somewhat better HTML5 compliance score, supposedly makes Chrome the powerhouse and Safari the also-ran.

Understand that the author seems to fail to realize that the difference between the XHTML and CSS rendering speeds between Safari and Chrome 8 are more than enough to make up the latter’s minuscule JavaScript advantage. Hail the new king indeed!

Unfortunately, the test gear wasn’t state of the art, employing a basic MacBook with 2GB of RAM, so this essentially represents a worst case scenario among current Mac hardware.

Besides, if the best browsers (and you can decide which should be first or second) do all their key processing tasks in less than a second, how does that impact your perceived performance?

The answer is that it doesn’t. Both Chrome 8 and Safari use Apple’s open source WebKit rendering engine, although the apps are clearly tuned differently to emphasize some performance factors over others. The real determinants of real world rendering speed lie elsewhere. Consider the speed of your broadband connection first, then the level of performance provided by the Web server you’re calling up when you visit a site.

A slow site may be due to the Web host, the kind of service (shared or dedicated, for example), and what software the site is using. These days, they’re apt to be database-driven, such as the super-popular WordPress, or a forum, such as vBulletin. There are loads of factors, which I won’t bore you by mentioning here, which conspire to make one site using software of this type seem slower than another. I will tell you in passing that I am very compulsive about testing all our sites to make sure we’re giving you the best possible performance.

All things being equal, a site may also seem slower as the result of the path the data takes to reach your Mac. If a server is located in another part of the country, or in another part of the world, precious milliseconds may be wasted in reaching your Mac.

In short, the tiny portion of rendering time consumed by your state-of-the-art browser and reasonably fast Mac form only a part of the time it takes for the site to display on your computer. Of course, one browser may delight for other reasons, such as the available feature set, or the ability to fine-tune using an extension of one sort or another. Here Firefox holds a huge advantage, even if its rendering time is subpar. In that respect, the rest hold up the rear.

But does any of this really matter all that much if you’re not a power user? That’s a decision you can answer only for yourself.