Safari 4.0.3 speed gains hobbled by unexplained poor AJAX performance

The latest security update to Apple's Safari 4 browser for Windows includes impressive speed gains in many departments, including page rendering -- gains the one-time speed champion desperately needs to remain competitive against Google Chrome 3. But a surprisingly poor performance score in one department -- declarations of AJAX objects on one of the tests in Betanews' benchmark suite -- is preventing the latest production version of Apple's browser from decidedly overpowering the latest production edition of Google's.

The third round of bug and security fixes and performance enhancements to the Mac work-alike browser slowed its performance index score on Windows XP Service Pack 3 to 16.01 from 16.16. But on Windows 7 RTM, Safari posted solid gains from 12.58 for build 530.19 to 13.09 for build 531.9.1, reflecting a nearly 5% gain on speed alone.

But the new Safari posted a particularly poor score -- much slower even than our index browser, Internet Explorer 7 on Vista SP2 -- in the AJAX declarations heat. That's a test from the Celtic Kane battery that does nothing more than time how long it takes the browser to create an XMLHttpRequest object in JavaScript, the principal object used in establishing a virtual communications link between server and client. (Since the benchmark test does literally nothing else with the object, its validity as a test in itself has been called into question in the past.)

Specifically, a heat where Safari 4 build 530.19 was timed at 23 ms, for a score of 8.96 (almost nine times faster than IE7 on Vista), yielded a time of 371 ms (0.56) for build 531.9.1.

Though yesterday's security advisory from Apple does not list XMLHttpRequest as one of the topics of its security fixes for this round, a known issue regarding malicious crafting of the object's header was reported by Apple two months ago. The exploit involved injecting a carriage return/line feed sequence into the header in such a way that WebKit, the rendering engine for Safari, could pass a request object as valid without a proper header to authenticate it. The header should affiliate the request with the Web site from which the script originated; WebKit normally runs with a same-origin policy.

The very sudden slowdown of this one feature in Safari suggests that Apple may have employed a stopgap measure to prevent new culminations of the same exploit. Since we've seen Apple release two different versions of the same "build" in succession before, it's possible that a follow-up release within the next few days could resolve the issue.

Apple's release yesterday was followed up by the beginning of the Beta 3 cycle for the Opera 10 browser for Windows. Once again, performance results for Opera have been a mixed bag, with a lower score on the Windows 7 RTM platform for build 1699 (5.07) than for build 1691 (5.31). On Windows XP SP3, the index score remained flat at 5.28. Opera now has the dubious distinction of having the only browser whose stable and beta versions register lower performance on Windows 7 RTM (4.40 and 5.07, respectively) than for Vista SP1 (4.43 and 5.27).

This while the latest daily build of the private Mozilla Firefox 3.6 Alpha 1 preview, code-named "Minefield" ("Namoroka" is the public preview), posted an XP score solidly above the 10 mark for the first time, at 10.41. Mozilla can now say its latest development build is twice as fast as that of Opera, which at one time not long ago boasted the fastest browser in the field.