Angular 2 how to improve DOM painting time on Internet Explorer 11

Question

Are there any special tricks in improving Angular 2 app performance on Internet Explorer 11?

Our site flies in both Chrome and Firefox but the DOM renders noticeably slowly on IE 11. I understand some of this is a limitation of the browser engine, but when a single change detection cycle causes 30-40 ms on DOM painting on IE 11, I feel like there's something else that can be done on our implementation. For the record, it never takes more than 1ms for Chrome to paint the DOM, so IE's behaving approximately 30 to 40 times slower than its counterpart.

Here's a IE11 snapshot of performance monitoring took on our localhost instance for DOM event (scroll).

Compare this to websites like The Guardian, which also uses Angular 2. Their site's DOM event handling time is almost always below 2 ms and what they display on DOM is far more complex than ours.

This leads me to think that there's some optimization techniques that's specifically suited for IE 11. Here's a list of things we've tried so far:

1. Migrated from SystemJS to Webpack. Helped with initial loading speed, but no difference in DOM painting duration.
2. We use core-js instead of es6-shim
3. Using pure pipes for formatting and avoiding any function calls from the template.

Any suggestions would be welcome.

Answer 1

Unfortunately, there's not just one thing that Angular does that causes issues with IE. Angular works heavily on DOM tree manipulation and child/parent node tracking, and IE's DOM tree isn't...really a tree. A lot of the performance issues for Angular on IE and Edge come from its change detection cycles - something that made Angular 1.X super cool but also gave it notoriety for getting clunky with size.

Angular 2+ did a lot to fix this, including giving developers many options to change this detection strategy to best suit the situation.

Change Detection Strategy

Here's a great resource for exploring this. Changing the ChangeDetectorRef service's detection strategy to `ChangeDetectionStrategy.OnPush' will cause Angular to only run change detection on component inputs. If you have a lot of static information in deeply nested components with no events bubbling up from the deeply nes, this could be a big speedup -- however, you will need to manually tweak the change detection when needed or manually call for a change detection sweep as needed -- not really as bad as it sounds, and will give a performance increase for all platforms.

Detaching the change detector

An even bigger performance boost would be to completely detach the change detector when users are doing things that fire off a lot of unneccesary rounds of change detection, like clicking and dragging. This can be used strategically to give rather huge boosts to performance, but how you implement it would be pretty application-specific.

Run Outside Angular

This will probably seem familiar, but if you have a lot of computationally heavy tasks that affect the UI, you can use NgZone to run logic outside of Angular's 'zone'. Probably doesn't have much effect on IE specifically, but a good practice nonetheless.

NgFor tracking

NgFor is miles more performant than the old ng-repeat, but it's still not perfect, especially when it comes to repaints (cough IE cough). This could be a big hit on IE performance specifically, due to how its DOM tree isn't actually a tree. By default, NgFor tears down the entire DOM tree for the repeat and rebuilds it for any little change made to its data. Giving NgFor a trackBy function allows it to only update the DOM where changes are needed, improving speed (especially if you have complex / numerous elements being repeated).

AOT compilation

More of a general boost than anything platform-specific, but definitely a good idea in any case. Configuring your app for ahead-of-time compilation takes out the Angular compiler from the build application and fully renders templates at build time. It can shave a lot off of load and render time, and can be even more impactful if you have large, complicated templates that can be built with minimal external data. It's a pain to do with Webpack or SystemJS (as opposed to CLI), but worth it. See the official docs here

Others

It's possible your issues aren't related to Angular at all - IE has performance issues with things like table rendering and certain styling situations (like calculating dynamic width for elements after a page render). Make sure to research any issues with what your app is implementing.

Good luck!