IE11 performance bottleneck

Alexey Antipov
5 min readJan 10, 2017

--

At one of the projects our team is working on we had huge performance problems in IE11 at some moment and here I want to share our experience how we resolved it.

The application had always been under active development and until some moment we tried to not pay much attention to performance issues. Our main target browser was Chrome and all seemed working fine. One day our business department said the main target browser is IE11 now and that it has huge performance problems we need to tackle somehow. I undertook to solve the problem.

To begin with…

To begin with, I decided to estimate the slowness of the application in IE11. I work remotely and don’t have a Windows machine at home, therefore I used BrowserStack to work with IE11.

Having been logged in and trying to do some actions, I could easily confirm that the app is very laggy. But I was in doubt regarding the additional BrowserStack impact, so I decided to check the performance of the app in Chrome via BrowserStack; it showed me that the app works way better in Chrome. Therefore I could confirm there are obvious huge performance problems with IE11.

The next step was to identify what exactly caused the problems. I used IE11 developer tools for that purpose. Here are the images I got.

IE11 styling performance before optimisation
Nodes styling in IE11 before optimisation

It speaks for itself — the main problem was with styling (the green bars are styling work). Styling of any single node at any page took 0.7–1ms vs 0.02–0.04ms at other websites, that is 30–50 times longer. So there definitely was something wrong with our css.

First guess

My first guess was that the problem was with the size of our stylesheets — we had megabytes of css. I removed unused css and tuned up the autoprefixer; it shrank the size of css to less then 500kb, but I still couldn’t see any performance gain. Сonsequently, I decided my guess was wrong.

Next guess

The next guess was attributes that we heavily used in our markup to style the document. I mean that we used custom attributes and their values instead of classes and id to style the elements (a weird approach in my opinion). I had read a lot of stuff identifying the use of attribute selectors in css as not a good idea, but all such recommendations were quite out-of-date and I couldn’t find any up-to-date information. Moreover, we didn’t have such problems with other browsers, IE11 only.

Anyway, to check my guess, I chose a little block of markup, replaced all the attributes by the appropriate classes and defined the styles for those classes. After that I measured the amount of time it took to style the nodes in the block. I couldn’t observe any change, the picture was still the same.

However I didn’t give up. I was certain that there was definitely something wrong with the attributes. The thing that gave me a confidence boost with that was that something very similar was suffered by the angular-material team a year and a half ago. Here are a couple of links to the issues:

According to those issues the reason of the deadly bad performance were the attribute selectors in css files and that changing them to classes did help.

Final guess

So my next guess was that mere presence of attribute selectors in css did affect the performance of style calculation for all the nodes even though the nodes might not have style attributes at all. To examine that, I had to do two things: change all the attributes with their values to the appropriate classes in our css files (less files actually) and do a similar thing for the markup.

The attributes approach is two-dimensional, because it takes into account both attributes names and values; on the other hand, the classes approach is one-dimensional because it just uses classes names. I worked out some simple rule on how to transform two-dimensional attributes to one-dimensional classes and then did the transformation with the help of regular expressions.

I really didn’t want to change the markup because there were lots of files with the markup, and all I wanted is just to verify my guess. So I came up with the idea that we can do the stuff with the help of directives. And I did it — for all the attributes I wrote the same directive that added appropriate classes to the nodes.

Then I checked the application and the result was fantastic — my guess was RIGHT! IT WORKED!

The styling performance achieved the level other applications and websites had in IE11 - styling work for every node took around 0.02–0.04 ms.

I solved the problem and I was happy! I hope the users are as well :)

As a conclusion

Therefore I could confirm that IE11 has the following performance bottleneck: the presence of attributes selectors in stylesheets really degrades the performance of style calculations for every node on the page. For this reason I do not recommend to use them in your css.

--

--