Internet Explorer slows down again: Is Microsoft messing up IE's JavaScript?

Over the last several weeks, but especially with the last round of Patch Tuesday updates, we've been noticing a severely downward trend in Microsoft's Internet Explorer performance -- a trend we were able to confirm in our most recent tests. It seems that with each security update, IE8's performance was cut in half.

This morning, Microsoft issued what its engineers describe (though without using the term directly) as a bug fix for one of last Tuesday's updates: a patch that addresses two newly discovered issues. One of those issues is a type mismatch error that would appear to become a potential security threat. If it's not a threat yet, then it could at least partly explain some of the severe performance issues we'd been seeing in recent days -- or at least so we thought.

This morning's support bulletin from Microsoft links to a patch for the patch, which Microsoft warns should not be applied unless the first patch has already been installed. This may be one reason why the new fix is not yet available on Microsoft Update and must be applied manually. We verified that the original 974455 patch was installed before applying patch 976749, and we hoped to see some verification of our theory that something bad was going on and that Microsoft was remedying it.

But the remedy may be worse than the problem, at least from a performance standpoint. After applying Microsoft's latest fix, we were shocked to find that IE8 performance on Windows 7 was only marginally faster overall than the performance of IE7 -- by most accounts, the slowest browser ever made -- on Windows Vista -- by most accounts, one of the slower platforms Microsoft ever produced (relative to the speed of hardware, Windows Me was probably slower). However, this was before we applied the new fix to IE7 on Vista -- yes, there are versions of the fix that go all the way back to IE 5.01.

Compared to the unpatched IE7 on Vista SP2, IE8 on Windows 7 was only 8% faster at rendering complex pages using DOM, 78% faster at rendering a non-CSS Web page ordinary HTML (at one time it was better than triple IE7's speed here), and 28% faster at managing complex page elements using JavaScript libraries and CSS selectors. The patched IE8 on Windows 7 was also 2% slower at rendering large tables, and 31% slower at rendering simple geometry.

In all, performance from Internet Explorer 8 on Windows 7 was 42% slower after applying the bug fix, than before the fix just last Friday. This estimate was made using Betanews' Comprehensive Relative Performance Index benchmark collection, which rates 69 different data points with respect to IE7 on Vista, which we use as our index browser.

Windows XP SP3 should be the fastest of Microsoft's three most recent Windows platforms, due mainly to the fact that the many additions that have greatly improved Windows security since the XP era did come with a speed cost. But our tests this morning after applying the 976749 patch showed IE8 was only 2% faster than IE7 on Vista SP2 at rendering pages using DOM, 48% faster in executing classic benchmark algorithmic tests, and 28% faster in executing common JavaScript instructions and methods. But it proved to be 26% slower at rendering simple geometry, and 16% slower at generating and manipulating large HTML tables.

Betanews tests show IE8 performance on Windows XP SP3 to be 38% slower after the bug fix was applied, than before.

Vista, ironically, was the least suffering platform of the three, with overall IE8 performance slipping only 15% after the bug fix was applied. In fact, many of IE8's best scores now show up on Vista rather than Windows 7. If we were to omit the bug patch for IE7, IE8 on Vista would score a 1.20 in our tests versus 1.17 on Win7. And our overall CRPI score, taking all three platforms into account, would be a 1.17 for IE8 today versus a 1.54 just last Friday -- a decline of nearly 25%.

However, we now expect that the same bug fix applied to IE7 to slow that browser down as well. As a result, our final adjusted scores may turn out somewhat similar to last week's since IE7 is our index browser -- they wouldn't reflect the degree to which IE7 slowed down. But the numbers for all the major independent browsers -- Firefox, Chrome, Safari, and Opera -- would probably rise. At least that's our expectation, and we'll be testing that theory next.

2:15 pm EST November 3, 2009 · As we suspected, Internet Explorer 7 performance is now somewhat lower as a result of implementing Microsoft's bug fix published today. But the performance gap between IE7 and IE8 was not restored by as much as we expected:

Prior to the bug fix, we measured the performance gap at about 17% overall. With the fix in place and with IE7 slowed down even more, the gap is now 35%. Vista is now the fastest platform for IE7, but not by much: about 2% over Windows 7, which is itself about 2% over Windows XP. It's completely counter-intuitive, but it's the new reality.

The other new reality is that the CRPI scores for all the other browsers scale up. They didn't all get faster all of a sudden; and the proportions between them remain the same. When you're figuring out which one is faster than the other, that's most important. But now Mozilla Firefox 3.6 Beta 1 posts a CRPI score above 15, at 15.02, whereas it was only 11.73 relative to IE7 in Vista just last Friday. Meanwhile, Google Chrome 3's score rises to a 26.48, again in proportion with the rest of the field.