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.




  1. […] This post was mentioned on Twitter by Dave Stanton, Veit Lehmann, Boye, Richard Millan, Kevin Decker and others. Kevin Decker said: RT @souders: CSS conditional comments ("[if IE 6]") hurt performance: […]

  2. […] Turns out IE conditionals around css files for IE6 can slow down your page load time in IE8! Crazy, right? The solution here avoids that, as does forcing IE to edge […]

  3. This is one reason why I use a simple JS trick to add the version of IE to the className of the HTML element. Then you don’t need a separate CSS file and (I believe) the CSS becomes much more maintainable.


  4. Another reason to use CSS hacks instead of conditional comments.

  5. I use an approach (not a “trick”) similar to what Thomas does, but then just a little bit more advanced: I add classes to the BODY element server-side, after analyzing the user agent string. See the BODY element at for an example.


  6. Stoyan said

    Nice catch!

    I did some more digging here:

    Regarding the solution – I think you see the positive effect because of a bug – an extra “endif” comment right before the meta tag on your test page. if you remove it (and you should, because it shows up on the page), the blocking comes back.

  7. […] came across this blog post (via @pornelski and @souders) where Markus has stumbled upon a case where an IE6-only stylesheet […]

  8. Markus Leptien said

    Thanks to Stoyan this article got an important update (2), be sure to read this. The initial fix was flawed, the correct one can be seen in the new Update.

    Kind regards,

  9. Paul Irish said

    Markus, could you post a test page?

  10. Hi Paul!

    Sure. Added it in the Post and here as well:

    Kind regards,

  11. Stoyan said

    Thanks for the update Markus, great stuff. So seems like encountering a conditional comment early on causes IE to parse through the rest of the page in advance and process the next comment too… Something like this, just guessing 🙂

    It’s a glitch and a little disappointing that you need an empty comment to fix a download sequence bug, but hey, we’ve seen worse. Plus I wasn’t too happy with the X-UA meta tag solution, at the very least because value “edge” is not recommended by the IE team. The MSDN page gives a less-than-ideal reason against “edge”, they say don’t use it, because future browsers may have unexpected behavior and the site might break, that’s why edge should only be used for testing. That kinda breaks the ideal of building future-proof web sites, doesn’t it? We *don’t* want to touch the site for every new browser version. But IE’s recommendation is still there. Anyway, I got a little off-topic 🙂

    Thanks again for sharing the discovery and the solution!

  12. Paul Irish said

    I totally agree about “edge”. It is, after all how we build sites for every other browser.
    Also, for everyone that has IE8 locked in there, when IE9 comes out, they wont be getting the canvas/svg/hardware accelerated DOM, etc.. Seems like an unwise move to lock your site to an inferior rendering engine.

  13. What happens when you remove the JavaScript from the head? Does the conditional CSS still block other content then?

  14. […] having started to analyze, how IE 8 interacts with our site in my recent post here, I observed another, to me, strange behaviour. We have read of course Steve Souders book High […]

  15. […] came across this blog post (via @pornelski and @souders) where Markus has stumbled upon a case where an IE6-only stylesheet […]

  16. […] scaricati anche i file che, grazie ai commenti, dovrebbe scaricare solo il 6 (come riportato su Webforscher’s Blog e su Ovviamente questo non dovrebbe succedere, ma spostando il tutto a inizio pagina […]

  17. […] Как вы видите дополнительные таблицы стилей не создаются, а создаются соответствующие классы под версии IE, которые присваиваются и опять же прячутся от других браузеров с помощью условных комментариев. Этот метод используется популярным HTML5 Boilerplate. Кроме того, данный метод исправляет проблему блокировки загрузки, обнаруженную Stoyan Stefanov и Markus Leptien, описанную в статье «IE 6 тормозит IE 8» . […]

  18. verbatim said

    I use a script that cuts out the need for CSS hacks AND conditionals:

    from the site: CSS Browser Selector is a very small javascript with just one line which empower CSS selectors. It gives you the ability to write specific CSS code for each operating system and each browser.

    It adds classes to the HTML tag that allows browser and platform specific CSS with no hacks.

    Even better: all the CSS validates, and no conditional CSS!!

  19. JohnAlbin said

    Does this conditional comment-related blocking still apply to IE9?

    • Haven’t tested this yet, but probably will do so, if time permits, next week. And update the results.

      Kind regards,

    • Just tested. Yes, it still does have the blocking effect.

      Kind regards,

      • JohnAlbin said

        Excellent! er… I mean, “Booo!”. But excellent that you tested it. Thanks! 🙂

  20. […] is only required for the bad browser. No one else gets it. According to some tests, it seems IE8 gets slowed down by IE6 conditionals. Very weird (and I'm not saying I actually care, either. ) __________________ Does, you'r. […]

  21. Thanks for the trick, I have tested myself.
    doesnot work for my styles.
    I have tested with placing before the original main stylesheet.
    And it works.
    with test result:
    with test results:

    • Hi Hiren!

      Yes, looking at the waterfall, the “trick” works also here, earlier on parallelization. But, for some reason, it doesn’t seem to pay-off in the Time-to-Render. There must be something strange happening here at the Backend, as with the old version the time to retrieve your only CSS file took roughly 300ms, while with the new version it now suddenly is never faster than a full second! That seems to be the reason, why it doesn’t pay off currently in the time to render. Can’t tell you though the root cause, why it suddently takes so much longer from the Server to send the CSS…

  22. […] Conditional comments can significantly slow your page down due to a browser bug in Internet Explorer 8. […]

  23. esthezia said


    In my opinion, the best solution is to deal with the specific CSS files server-side, meaning echo-ing / loading the specific CSS based on a user agent verification made in the server-side language.

RSS feed for comments on this post · TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: