Security fixes, JavaScript update bog down Internet Explorer 8

The final test editions of Microsoft's Internet Explorer 8, released while Windows 7 was still in the technical preview phase, suggested that its performance could very well triple that of its predecessor, the venerable IE7. When the RTM edition first became available, its performance was pared down a bit, but still better than double that of IE7, based on Betanews' assessments at the time.

But we've noticed a trend of IE8 performance dragging down over time, while every other major Windows browser in the field was headed the other direction -- and fast. Early this month, when Firefox 3.6 Beta 1 appeared imminent (and still is at this moment), we calculated the performance difference between IE8 and IE7 at about 75%.

After the last round of security fixes two weeks ago, plus an out-of-cycle update to Microsoft's JavaScript (JScript) engine this week, the performance gap across Windows platforms has averaged down even more, to an all-time low of 54%. This even though Betanews tweaked its testing suite even more in the last few weeks, in response to changing circumstances with one of our benchmark providers -- our CRPI suite now includes a few test batteries that should have cut IE8 some slack.

In our latest round of tests, IE8 scored a CRPI of 1.54, which means on average, users can expect 54 better overall performance from IE8 than they would have seen from IE7 running on Windows Vista SP2.

We also could not help but notice that the latest JScript update was applied to Windows XP and Vista platforms only -- at least in the Automatic Updates distributions that we received. After those updates were applied, IE8 performance in Vista and XP were dragged down so heavily that IE8 on Windows 7 is now the fastest of the three platforms: 1.63 for Win7 versus 1.59 for XP and 1.41 for Vista. Since we've been testing on the Windows 7 RTM platform, browsers have typically been 10 to 15% faster on XP SP3 than on Win7.

What happened? First of all, we've noticed that since Patch Tuesday, IE8 has completely failed the portion of the advanced SlickSpeed selectors test that focuses on the browser's native JavaScript library, on all three platforms ("failed" meaning, it couldn't perform the programmed job on all 56 heats). This is the one portion of the SlickSpeed test that IE8 used to perform quite well on. On XP over the past few weeks, IE8's score on SlickSpeed slipped from 2.45 on October 13, to 1.67 yesterday.

Meanwhile, the SunSpider test suite written by the WebKit team shows a noticeable slowdown in the calculation department in all categories, but again, on XP and Vista and not Windows 7. On XP, IE8's SunSpider score slipped from a 6.02 to a 5.79. On Windows 7, meanwhile, the SunSpider score improved from a 5.66 to a 5.93. (These scores are relative; a 6.00 would mean "six times faster than IE7 on Vista SP2." We post relative scores on tests using identical hardware in order that the hardware can be factored out of the equation; in other words, we believe IE8 is only 54% faster than IE7 on any machine you choose.)

It's computational test scores where IE8 is flagging; by comparison, rendering scores are flat to slightly higher across the board. We're still in the midst of tallying scores for other browsers, and plan to post those results along with test scores for the first public Mozilla Firefox 3.6 Beta 1 once that browser (finally) becomes available.

Some Betanews readers have asked us why we use IE7 on Vista as our performance index rather than IE8, and up to now, our answer has been because it's the slowest browser we test, and thus gives us a more granular sense of performance improvements for all the more modern browsers in current use. If this trend keeps up, though, we may just change our minds.