IE11 scrollable element performance with large/complex DOM

[stevenmiles]

In IE11 a scrollable element that contains a large DOM performs poorly when interacting with that elements scrollbar.

http://codepen.io/stevenmiles/pen/jPaZJL

Clicking the arrows on the scrollbar, clicking in the scrollbar to move the bar up/down and trying to drag the scrollbar are extremely laggy.

Behaviours:

• Removing angular-material.css restores the scrollbar to normal operation.
• Only affects scrollable elements. The body scrollbar seems unaffected. However body scrollbar is hardy ever used due to the use of toolbar, sidenav and content components.
• A UI responsiveness profile in IE11 shows that when clicking the scrollbar a style calculation is performed which is causing the laggy behaviour.
• When angular-material.css is included, a style calculation is caused whenever the scrollbar is clicked.
• The inordinate amount of universal attribute selectors in angular-material.css cause style calculations in IE11 to take an excessive amount of time for large DOMs. (also an issue for any component that might trigger a style calculation or layout i.e md-tabs)

Notes:

• No angular-material styles/attributes are used on any element in the codepen above
• There are no watchers. The DOM is built in a directive to keep the codepen small. There are no bindings that will trigger a watch.
• Obviously affects md-content as it is a scrollable element.

[demsey2]

we have a similar issue with ie11, my comment here #1771 (comment)

we don't use layout so we have removed all layout attributes from angular-material.css and that helped a lot

[stevenmiles]

@demsey2 I guess you didn't remove all layout attributes as some of the angular material components use some of the styles?

The performance issue in IE11 would probably go away if we could use class selectors instead of universal attribute selectors.

Something like

<div class="layout-row">
  <span class="flex-33">Hello</span><span class="flex-66">world</span>  
</div>

I guess there might be too much invested in the universal attribute selector base for the layout system to change though.

I wonder if it's feasible to automate a 'post processing' build to convert universal attribute selectors and their use in the md-* components to class selectors?

[demsey2]

At the moment we use only a couple components from angular design so it was safe for us to remove all layout attributes.

I agree class selectors would help. I am surprised that ie11 issues are not reported by more developers. Just have a look at https://www.google.com.au/trends/ with IE, it's so slow!!!

[Splaktar]

This could be related to a number of recent performance issues seen in IE 11 due to recent updates:

Massive performance issues with tables and complex DOM - https://connect.microsoft.com/IE/Feedback/Details/1271727
Rendering performance issues with innerHtml -https://connect.microsoft.com/IE/Feedback/Details/1324313
Large lists (>300 items) seeing a considerable slowdown after update - https://connect.microsoft.com/IE/Feedback/Details/1269380
IE11 has a massive perf problem with deep height cascade chains - https://connect.microsoft.com/IE/Feedback/Details/1415980

Some people claim that uninstalling/installing certain patches has helped their performance. I suspect that this is due to IE 11 performance issues around nested flexbox layouts.

[stevenmiles]

@Splaktar

Notes in relation to codepen used to report original issue. http://codepen.io/stevenmiles/pen/jPaZJL

Massive performance issues with tables and complex DOM -

No tables used

Rendering performance issues with innerHtml -

No innerHtml used other than to render the html once.

I suspect that this is due to IE 11 performance issues around nested flexbox layouts.

No flexbox layouts used. No MD components used that might use flexbox.

Large lists (>300 items) seeing a considerable slowdown after update - >https://connect.microsoft.com/IE/Feedback/Details/1269380
IE11 has a massive perf problem with deep height cascade chains - >https://connect.microsoft.com/IE/Feedback/Details/1415980

No issues with scrolling performance when MD css is removed.

[ThomasBurleson]

Large DOM with ng-repeat:

Here is a CodePen Demo and Timeline snapshot of the Large DOM using ng-Repeat:

With 500 Row items

With 2000 row items:

Large DOM with md-virtual-repeat:

Here is a CodePen Demo and Timeline snapshot of the Large DOM using ng-Repeat:

You can see the initial md-virtual-repeat render performance is ~4x faster and uses 20% of DOM elements. Even better... if you increase the number of row items [from 500] to 2000, the timeline is relatively unchanged. So scaling does not affect performance.

Thx to @jelbourn and @kseamon for this excellent component.

---

It should be noted that a general rule of thumb is to NOT render all your model data; instead use UX to determine the view model data that should be rendered; where the view model is a subset of the model data.

[stevenmiles]

I have seen virtual repeat. However, variable height records seem to be a difficult problem to solve with virtualised scrolling. Does md-virtual-repeat provide a solution to this?

It should be noted that a general rule of thumb is to NOT render all your model data; instead use UX to determine the view model data that should be rendered; where the view model is a subset of the model data.

We are having do such a thing, however this isn't because it will improve UX in and of itself, but because MD currently burdens us with poor performance (and poor UX) if we don't.

Performance issues with ng-repeat and the way angularjs does many individual "set element value" (even with one way bind) can be avoided though generating html. See codepen in OP

I think issue here is not necessarily that style calculation performance is bad in IE with MD css (that is a seperate issue), but that style recalculations are caused seemingly needlessly when interacting with non body scrollbars.

[stevenmiles]

I've just noticed the same scroll bar lagging in IE11 for the Angular Material documentation. https://material.angularjs.org/HEAD/#/

Expand the Demos section and try dragging the scrollbar there is a noticeable lag before the scrollbar start scrolling.

[joneal]

I have been fighting the IE11 / scrolling lag issue for a couple of days. Have an HTML table using ng-repeat. Thought issue was number of watches, so replaced ng-repeat with React generated table via an Angular directive. Performance still terrible until I removed angular-material.css. Now IE11 is happy, even when going back to ng-repeat.

[Splaktar]

That's helpful! Thank you.

[stevenmiles]

@joneal

I took essentially the same route. I was inspired by NgReact http://davidandsuzi.com/ngreact-react-components-in-angular/. Except I just generated the html myself in a directive. This improved page initialisation, however it didn't fix the scrolling issue. As you say, only removing the angular-material.css made difference to scrolling.

@Splaktar

I took steps avoid any angularjs performance issues and was left with just the scroll lag. This is all detailed in the OP. The codepen in the OP might be helpful. It exaggerates the scroll perf issues without angular performance issues getting in the way.

http://codepen.io/stevenmiles/pen/jPaZJL

[Splaktar]

@stevenmiles thank you for the detailed information. I am able to reproduce this and there is a large difference in the behavior of IE 11 vs Chrome/Firefox on the provided CodePen and on the Angular Material docs site. I am working on isolating the exact CSS that is causing this issue now and should have some more information this weekend.

[Splaktar]

I've got this running locally with the latest angular-material.css from master in IE 11.

1. With the material CSS, scroll bar interactions with the mouse cause a 1580 ms style calculation to occur.
2. With all of the layout and flex styles removed from angular-material.cc, scroll bar interactions with the mouse cause an 82 ms style calculation to occur.
3. Without the material CSS, but with Bootstrap CSS, scroll bar interactions with the mouse cause an 95 ms style calculation to occur.
4. Without the material CSS, scroll bar interactions with the mouse cause no style calculations to occur because there are no styles applied to the page.

Bootstrap uses quite a few attribute selectors, so I don't believe that those are causing this issue in IE. Bootstrap has no Flexbox layout styles at all.

I am still under the impression that IE 11 is not properly handling Flexbox layout styles, even if they are not used in the page (as in the provided CodePen).

[Splaktar]

Just tested both the CodePen and Demo scrollbar with MS Edge 20.10162.0.0 due in Windows 10 on 7/29. There is no scrollbar lag or slowness in either example. Also looking at the Performance tab, scrolling with the mouse causes no style calculations at all, same as Chrome and Firefox.

So as far as I can tell, this is an IE 11 issue that will be fixed in MS Edge for Win 10.

[stevenmiles]

So as far as I can tell, this is an IE 11 issue that will be fixed in MS Edge for Win 10.

Unfortunately this means that the browser fix is Windows 10 only and then only Edge browser.

http://www.pcworld.com/article/2901701/internet-explorer-11-wont-use-microsofts-new-edge-browser-engine-in-windows-10.html

The important part to this is OS support of Edge. Microsoft has yet to announce Windows 7/8.1 support for Edge, and given their track record, I can assume we will be stuck with supporting IE11 as the only MS browser for older operating systems. In addition IE11 will still be with installed with Windows 10 as an alternative for intranet sites.

As far as I see it IE vNext != Edge. Edge is a totally new browser.

[Splaktar]

Yep, it's certainly a problem that IE doesn't have the same kind of update process as Firefox and Chrome. Firefox used to have performance issues with Flexbox layouts very similar to this a few months ago, but the latest versions of Firefox have solved this. I wouldn't count on IE getting really solid Flexbox support as they are going to be putting all of their focus on Edge (AFAIK).

[begemott]

I have the same issue and spent some time to investigate it. It looks like the problem is in src/core/style/layout.scss. When I commented whole content of this file the performance was OK. Then I replaced attribute selectors with class selectors and performance was OK. So I think that the problem is not in the Flexbox layout but in the attribute selectors. IE processes this type of selectors very slow.

[eXaminator]

We can affirm this with our own tests even outside of angular material. IE seems to be extremely slow when it comes to attribute selectors.

[ThomasBurleson]

The Angular Core team needs to discuss how we will respond to this particular IE Layout Attribute performance issue.

[MetalHexx]

+1 big lag scroll issue in IE 11 with large list of items (200 in this case). Remove CSS and blazing fast performance. One interesting thing to note it hat IE performs alright just using the mouse wheel to scroll through the items. It only seems to bonk when a single click to anywhere in the scrollable area occurs (even white space).

And to @stevenmiles point: I was invited to the Microsoft Insider pre-party recently and I got a chance to speak to one of the developers on the edge browser. He confirmed to me that Edge will be Windows 10+ only. So writing off a fix for IE 11 on the grounds that Edge fixes the issue is alienating anyone not on Windows 10.

[rschmukler]

@MetalHexx can you see if taking a class based approach with the layout resolves the speed issues? We are trying to figure out if IE11 is having performance issues with attribute selectors or whether it is flexbox that is causing the issue.

We will be doing a more formal performance audit to get to the bottom of this, but any feedback from users will also help us get started.

[MetalHexx]

@rschmukler Our designer is trying a class based approach with a different flexbox as we speak. I'll update you with the results.

[eXaminator]

We used the layout part of angular material in one of our projects (nothing else was used from angular material). We had some big performance problems (not just scrolling but in general) in IE 10 and 11 (luckily we don't need to support older IEs). We managed to pinpoint the problem to the layout / flex attributes. Some tests showed it is due to the attribute selectors. We actually changed all styles to use classes and wrote some directives to add the classes based on the attributes. This way we didn't need to change the rest of the code and we got a big performance increase.

So I can confirm that the problem will be solved (or at least greatly improved).

[rschmukler]

@MetalHexx awesome, we look forward to hearing back. It's a huge help.

@eXaminator thanks a ton for the feedback! Good to hear.

[MetalHexx]

@rschmukler, So our designer @ryanespin, tried removing all the flex and layout attributes from our problem page and we still saw the same problems (maybe the other md directives we've implemented use them?). He then removed the flex and layout definitions from the CSS file itself and the performance has dramatically improved.

[rschmukler]

@MetalHexx so it is having lots of attribute selectors to check against that is likely causing the issue? Have you tried porting things to classes and seeing if that works?

[ajoslin]

Just chiming in: I'd guess it's flexbox having performance issues, not the attribute selectors.

At Ionic we saw issues just scrolling large lists of flex elements versus block elements.

[eXaminator]

I don't know about flexbox, but attribute selectors definetly have a problem. It's actually quite known that class selectors are the fastest. And as I say we still use flexbox (via classes) which works far better then before (not perfect though, but we could still have other performance problems in other areas of our application).

By the way: This is mostly true if the attribute (or anything beside class or id) is the "key" part (last part) of a selector as selectors are parsed right to left. This means a selector like .class tag [attribute] is slow because it seems to search for all(!) elements matching [attribute] (which is said to be pretty slow in about all browsers) and then starts filtering those attributes by looking at its parents, while tag [attribute] .class would first search for elements having the class which is supposed to be a lot faster.

I read some articles, blog posts and other stuff about this and this seems to be a problem in all browsers, though other browsers are usually faster in this regard and so you don't really notice (I don't know the specifics though).

[MetalHexx]

@rschmukler We have not tried porting anything to class selectors yet as we're not in a rush. We merely commented out the layout styles in the MD CSS file.

[stevenmiles]

@rschmukler

The codepen from the OP (http://codepen.io/stevenmiles/pen/jPaZJL) doesn't have any flexbox layout at all and the scrollbar still behaves badly. Obviously the universal attribute selectors are there, but as fas as I can tell, they shouldn't actually be applied, from my understanding, it just takes a long time to figure out that they don't need to be applied.

CSSLint has a warning about exactly the type of selectors that layout uses

https://github.com/CSSLint/csslint/wiki/Disallow-unqualified-attribute-selectors

[stevenmiles]

@rschmukler I converted all flex layout to class selectors in another codepen. scrolling performance issues went away.

Before: http://codepen.io/stevenmiles/pen/jPaZJL
After: http://codepen.io/stevenmiles/pen/MwRQXY

Both codepens are 0.10.1

[rschmukler]

@stevenmiles super helpful codepens. Thanks a ton for the effort! Will take this to the team and figure out how to tackle this.

[stevenmiles]

#4282 by @paulflo150 has improved the IE style calculations by changing all universal attribute selectors to class selectors. He added backwards compatibility by adding directives for the attributes that add the classes to elements. I would imagine that using the class selectors directly would be the best for performance though, especially when a lot of layout attributes (now directives) are used.

Most of the discussion seems to have happened in #1771

This has solved the scrolling issues I was seeing with IE11. No scrollbar lag in this codepen http://codepen.io/stevenmiles/pen/MwNJWd in IE11.

Thanks @paulflo150 and @ThomasBurleson!

[ThomasBurleson]

@stevenmiles - thanks again for your research and the CodePens.

[Splaktar]

That is great news! The key was the idea to create those directives to maintain backwards compatibility. Without that, I was uncomfortable making such a large breaking change this close to 1.0. Very glad that we found a way to have our cake and eat it too ☺

[stevenmiles]

@Splaktar yes, the directives made me happy too. ☺

However, one question I do have, should layout attributes(directives) be deprecated before 1.0 and eventually removed? Given that the layout directives are essentially a less direct way to add a class to an element, should Angular Material, as a library, encourage direct usage of the classes over directives before 1.0 is reached.

@ThomasBurleson I guess that's probably a question for the dev team ☺

[ThomasBurleson]

@stevenmiles - Regarding remove layout directives (and require developers to use layout classes):

I worry about a learning curve and possible errors for directly entering layout class selectors; while using the layout directives is super easy... With the recent changes to use the directive compile phase, I think many of the remaining performance concerns will be addressed.

[jrgleason]

Thanks I had a huge app and it did help to convert to classes. What about other attributes like md-border-bottom as in md-tabs.flex-grow(md-border-bottom, md-selected="ctrl.selectedIndex")?

[stanciupaul]

Angular material CSS was causing incredible slow performance for our application on Microsoft Edge, lagging the entire interface. We solve the issue by removing it.