All throughout the testing phase of Mozilla's Firefox 3.5, we've been tracking the often very granular, very minor speed tweaks that developers have been making to the browser -- a one percent improvement here, a two percent dip there. And some of our readers have been wondering why. With computers that are already fast enough for many consumers, will it matter much that Google Chrome completes some operations in two blinks of an eye versus Firefox's three blinks?

We posed those questions to two of Mozilla's browser engineers: Senior Director for Platform Engineering Damon Sicore, and infrastructure developer Vladimir Vukicevic. Their answers include items we can share with you directly, and demonstrate to you explicitly.

A few percentage points here and there is the complete difference between whether some of the browser's new functionality works fluidly or doesn't really work at all. One test you can see for yourself is on one of Vukicevic's test pages: a high-contrast landscape photo complete with sliders that control the photo's relative brightness and contrast. Live image manipulation isn't particularly exciting, especially for folks who see this sort of thing in Paint Shop Pro.

But slide these two sliders around for yourself in Firefox 3.5, and watch how fluidly the browser responds to your motions, producing updates as fast as 12 frames per second on Betanews' quad-core test system. Then try this same page on Firefox 3.0, or something even older.

"What's important here is how fast the actual adjustment occurs, and how many frames per second you can get while doing this," Mozilla's Sicore told Betanews. "With Firefox 2, you get 0.18 fps, which is almost unusable. Your laptop will heat up, and it doesn't really necessarily enable you to make the changes you want to the actual image. But as we use Firefox 3.5, we can get 8.1 fps, and [even more increases] by tuning the JavaScript just a little bit." Betanews tests estimate that Firefox 3.5 performs with about 251% the speed of the final stable Firefox 3.0.11, in repetitive benchmarks. Those are the tools engineers use to reveal areas of the JavaScript engine that require improvement. In this particular test, the differences are way beyond 251%. In fact, with Betanews tests of this same page using Firefox 3.0 on the same system, after playing roughly, we were able to freeze the browser completely.

"One of the things we've been trying to do is figure out, what are the kinds of actions and applications that we want to see show up on the Web, that are greatly helped by having a faster JavaScript engine?" remarked Vukicevic. "What are the things you couldn't do before that you can now, once you have a significantly improved JavaScript engine? We use [benchmarks] to judge either peak performance, or performance under very specific conditions."

"In the TraceMonkey engine itself," Sicore added, "inside of JavaScript, we've focused on key performance benchmarks that we feel will reflect how the Web is being used today by people."

Another extraordinary demonstration of what a tad more speed makes possible, is the inline video/graphics injection demonstration we unveiled last week. There, an inline video played by 3.5's new inline video rendering engine can receive live overlays from any of six other graphical sources on the page, without slowing down the movie. This is the kind of mixing that has historically been the realm of fully compiled applications. But this is JavaScript, Web code, stuff you get online.

When you're developing a compiler or a language interpreter (which isn't just the engine for Firefox but also its "chassis," if you will), there is a performance threshold below which some functions such as this are not possible. Making Web engines faster by tenths of a degree makes feasible new classes of online applications that could not happen no matter how much faster the underlying computer becomes.

As one Betanews reader named Nick asked me via e-mail earlier this week, though, does that window of opportunity have a ceiling on the opposite side? Or as Nick put it: "I think it's great that all the main browsers are working to improve performance. The consumer actually wins! The improvements over the past five years have been so dramatic. But now, are we comparing three cars and how fast they can go from 80 to 100 mph, but the speed limit is only 65? In other words, can the human eye notice anything below a half-second? Another way to put the question, does Firefox, Chrome and Safari now get a A+ in performance, IE 8 get a 8 and IE 7 gets a C and IE6 gets a D-minus? [And] if so, is A+ the best they can get?"

If the speed limit were something set by the human eye alone, then perhaps the answer to this would be, "Yes." That's if we presume that all that a Web browser will ever do is recite Web pages like the one you're reading now. But as Mozilla and its competitors understand, that's not all the Web will be. For too many years, the speed of everyday processors has been locked away from the novice or experimental developer, only to be tapped through low-level languages such as C++ and C#. In the beginning of the computing era, BASIC was the way we learned to use our machines; today, typical users are no more compelled to program their own applications than to build their own automobiles.

Making JavaScript faster changes this equation, shifting the balance more toward where it used to be when the craft of computing was conceived. The feasibility of doing things like live video mixing through high-level languages (those that use interpreters) sets new speed targets that developers at Mozilla and Google, and evidently Apple and Microsoft (and our Opera readers will chime in at this point), will endeavor to reach. This week, Mozilla has reached that bar; I have no doubt that Google, whose Chrome browser already has a faster engine, will meet this challenge in due course.

But when the next class of applications makes itself feasible on a higher level (multiplayer online 3D games, anyone?), then suddenly "A+" will become more like "C." And the competitors in that field (assuming no one's messed up the Web browser market a second time) will endeavor to meet this new target. There may be a dozen or so people who don't really care, at least not at first, because Betanews will render pretty much the same in whatever new browser that comes along. But there will be a different class of developer, one who isn't as pleased with Nissan's 350Z as with the 370Z, who will raise his own expectations and who will contribute to the act of setting the bar higher.