IE 6 slowing down IE 8

Hi there!

As most of you know, performance improvement is an ongoing effort. Pages change, new stuff arrives, and your once so fast and optimized page becomes slower and slower… So it is good, to check your page regularly. Which I did with our site

When doing this, with the great help of, I stumbled across some interesting behaviour with IE 8. So let’s see, what we got here. The beginning of the page loads like this in a waterfall chart:

What caught my suspicion was the strange “gap” between combobox.css and errorboxes.css.css (sic!).

What is happening there? IE8, by default using 6 connections in parallel with HTTP1.1, is simply waiting ~0,15 seconds apparantly doing nothing. And then re-using its connections, to fetch two further CSS files. What happens here?

So I looked at the source of the page, and this is what I found right between these two objects:

<!–[if IE 6]> <link rel=”stylesheet” type=”text/css” href=””/&gt; <![endif]–>

Hmmm… Weird. This is an CSS file, that only IE 6 should load, to fix some CSS issues with that Browser. IE 8 should not be affected by this at all, and the Waterfall indeed showed, that the asset is not downloaded. Well, let’s try and see what happens, if I remove this comment from the source code.

Voila! The “gap” is gone. And IE 8 fetches all the CSS files at once, using all 6 connections in parallel. So we found the culprit.

Unfortunately simply removing this is not an option, as obviously somebody wanted on purpose a backwards compatibility to IE 6. And I was curious, if it could be fixed, by simply doing some re-sorting.  So my first try was to place this piece of code right BEHIND the regular CSS files. And the result was this:

Hm, unfortunately not really a leap forward. We simply have moved the “gap” from within the CSS files now to a position behind the files, right in front of JS files.

Other try. Let’s put it first! And the result is:

Wow, this comes a suprise. The “gap” is gone! I was pretty glad with that result, up until one of our Web Designers told me, that even though this looks pretty nice, I probably would break the functionality by doing so. Because IE 6 would load its CSS fixes, and when afterwards loading the default CSS objects, would overwrite its own fixes. We have to check on that.

So maybe it would be better, to deliver IE6 its own page by varying by User-Agent or whatsoever.  But the lesson I learnt now: Using the current mechanism for IE 6 surprisingly puts quite some penalty on IE 8. If possible, avoid this approach.

With a time to render of 1 second that our page has, this effect is responsible for 15% of that.

In case somebody knows a best practice, that doesn’t come with penalties, please feel free to comment.


Seems there is indeed a best practice, that solves the issue, without breaking functionality. And is easy. A small snippet of code solves the issue, placed in the HEAD before any CSS/JS Files being loaded. It looks like this:

<meta http-equiv=”X-UA-Compatible” content=”IE=edge” />

Meanwhile our page has changed a bit, concatenating most of the CSS files. So let me show you just briefly the Waterfall BEFORE adding this code:

And now AFTER this code has been added to the HEAD in front of loading the CSS Files:

Done! 🙂

Update 2:

Thanks to Stoyan, who found a serious flaw with my solution, which you can see in the comments below.

So I was going back to one of my initial ideas, putting the conditional comment in front of ALL CSS-Files. But this time, I left it empty. And had a second one, were it was originally placed, right between the two CSS-Files, which would be used as intended, to download the file.

What can I say, now it works, and IE 6 still gets its CSS File.

So the correct, stupid, solution is, to place this code before any CSS/JS gets loaded:

<!–[if IE]><![endif]–>

Visible here:

Sometimes reality bites… The first solution was from an analytical point much more convincing. 🙂 Now I do have an workaround, but with the much more unsatisfying feeling left, to not really understanding, why it works.

Thanks to Stoyan for finding this serious flaw!

Update 3:

I have seen in some boards recently a lot of comments like “Well, 0.15 seconds… So what. I won’t fix this just for a tenth of a second.” Be carefully: The delay depends on your specific site! Or, to be more precise: The transfer time of the CSS, that is loaded directly BEFORE the Conditional Comment.

Here is another case from, where the delay is almost half a second (!), instead of a tenth of a second:

With a time to render of 1.2 seconds, this is a good third  of it!

So you should test your sites behaviour, before deciding not to tackle this issue.


Comments (29)

Strange IE behaviour with SSL connections

Hi there!

We stumbled upon a strange SSL/CCS Issue with IE6 and IE7 when we were tuning our homepage Alice. Found was this issue with Pat Meenans Pagetest and HTTPWatch. I am a little bit puzzled and still have not drawn conclusions yet. So here is what happened. For those not familiar with Pats Tool: Dark green is DNS Lookup, Orange is TCP Connection Setup, pink is SSL Handshake, Green is Time-to-first-Byte, and Blue is Data being received.

As the page is done via a Content Management System, we picked one page, which is pretty much representative how all the pages are constructed. The page we picked was this Rechnung, as it is delivered via SSL like almost all of the pages, but does not yet need authentication.

We first had a page with tons of assets. Something like 15 Javascripts in the HEAD, 30 CSS Files in the HEAD, and 20 Images and 20 CSS Images.  The page is normally delivered via SSL, so the initial Connection View of it looked like this:

Clearly you can see it starts to download the CSS and Javascript files on the two sockets IE7 allows per domain. Also you can see between 1.5s and 5.5s the blocking behavior of the Javascript files. Even though having two connections, it doesn’t  use them in parallel.

At roughly 5 seconds it has completed that, starts to render, and downloads all the images. So far so bad.

So we started to optimize and first concatenated all the 30 CSS files to just 5, one being IE7fixes.CSS. This gave us some improvement. You can see that a lot less CSS objects get fetched at the beginning. (The first 4 items are actually newly introduced Redirects due to an Single-Sign-On Service. Yikes.)

But you can still see the painful blocking behavior of the Javascript files.

So what we did then was to concatenate the Javascript files and introduce a second (static) domain, were we would put all the static content. Apart of the Basepage and the Javascript file, everything should reside there, Cookie-free.

And the result is this:

And this seriously puzzled me.  What we see here are at

Line 1 the Redirects and the download of the Basepage.

Line 2 download of the concatenated Javascript file, which is still on the first domain.

Line 3-7 A wonderful waterfall of two connections, with a full TCP and SSL Handshake for EACH CSS FILE…

Line 6-7 The last two SSL Connections are then reused for fetching all the images.

So what is so special about these CSS Files??? HTTP Headers are the same for all of them. Both, Request and Response Headers are HTTP/1.1 with the Header Connection: Keep-alive. And as you can see, for the images it works fine. Why not for the CSS assets?

I did a Wireshark trace and saw, that it is actually me (the Browser) who closes the connection. After receiving the data, I am sending a TCP FIN,ACK. Why does it do so?

So I tested a little bit more and found out, that this behavior is visible with IE6 on XP and IE7 on XP and Vista.

Tests with IE8 on XP showed a totally different picture. Here I got:

Now this is fine. You can see in

Line 1 and 2 that two sockets are used for the Redirects, the basepage, the Javascript and the favicon.

Line 3-4 Opening up 2 new connections to the second, static, domain to fetch the CSS files

Line 5-8 Opening up 4 more connections reaching the maximum limit of 6 connections per domain to fetch all the other assets.

THIS is how I expected the whole thing from the beginning. So I wonder what is going on with IE 6 and IE 7…?

As a final note I tried to fetch the page with IE7 via plain HTTP, no SSL. This is to some degree possible, but leaves me even more puzzled. Here it is:

Line 1 fetches the Basepage and the Javascript file via plain HTTP

Line 2 are the SSO Redirects via HTTPs

Line 3-4 are the CSS files, where it reuses the connection via Plain HTTP, and later on some images

Line 5-6 is fetching two CSS Images via SSL. These connections are NOT reused.

Line 7 fetches some more images

Line 8-13, 15 again a perfect two-connections per domain waterfall, where again CSS Images are pulled via SSL, NOT reusing these connections.

Line 14, 16 some more Images a fetched via plain HTTP, reusing the connection

So we have here with Plain HTTP a reuse of the connections for the CSS Files, the CSS Images though, fetched via SSL, show again the pattern of NOT reusing the connection.

Currently my assumption is, that IE6 and IE7 show this broken behavior, if the following is true:

MULTIPLE CSS Files, served from a DIFFERENT Domain, when fetched via SSL.

A final test would be, to put the CSS files (maybe even the CSS Images?) back on the first domain, and see what happens.

I searched a lot, but was unable to find any known bug for this. If this is indeed a bug and I am not totally misleaded with this analysis.

Any comments/help would be highly appreciated, if this is a known bug, a mistake by myself, or a workaround exists.


P.S.: In case you wonder: Some of the traces were taken from the UK, some from the US. So do not wonder about the different times to fully download etc.

Comments (3)

« Newer Posts