I have an angular material SPA web site that performs very well in Chrome, Firefox and Edge, but it lags massively in IE11.
I am aware of angular material issues with animations and styles in IE11 and have made several changes to improve general performance in that area (disable animations, even removing theming, etc...).
But, even if that improves the application slightly, I can still see a massive lag when loading resources, where every request spends a long (really long time) to be processed. I have checked the server and the response is always in the milliseconds range (as it is in Chrome), but it takes forever in IE11.
Please check the load network times for IE11.
Any ideas of what might be causing this?
I had similar issue with AngularJS in IE we tracked our issue to a security update for IE (KB2962872). Uninstalling that patch brought performance back up to normal.
You might investigate that XMLHttpRequest gets intercepted. While modern browsers performance penalty on this is smaller, for IE exchanging native calls with JS functions impacts to a certain degree and scales with its usage. This applies to a variety of polyfills and extended functionality.
Based on your screen shots, it looks like there may be a bottleneck around the "CORS Preflight " Requests.... Perhaps this https://developer.akamai.com/blog/2015/08/17/performance-single-page-apps would explain a viable work around for you.
Furthermore, I would look into why your application is making a slew of OPTION requests, unless that is intended, you application is making many round trips, each delaying the next, and with a limit on concurrent connections you end up consuming the pool and blocking further requests...
It would be interesting to see what is happening over the network, via IE's network tab...
This looks like
XMLHttpRequest is queuing up and then being executed in a batch, essentially stalling every request until some internal process sends them all at once.
The first place I'd investigate is that IE has (poorly documented) internal limits on how many concurrent
XMLHttpRequest and browser requests it will allow at once. In older versions this was 2, but it increased around IE8 to up to 6 depending on some awful and unreliable internal metric as to how fast IE thought your network is. IE11 still does this, but has a higher limit.
My guess would be that you have hit this limit, and once you have hit it the internal timer check that manages the batches in IE is taking 1-2s before it sends another set to the server.
To test this hypothesis: in IE11 only add a 100ms wait (it just needs to be enough to throttle the number of parallel requests) before sending every request. It will still be awful slow, but if internal batching is the cause you won't see the 1-2s delay in blocks on the requests.
If that is the problem the fix may be some kind of batching yourself to try and avoid hitting IE's cap, but as that is dynamic I suspect it will be a disproportionate amount of pain for <1.5% of users.
©2020 All rights reserved.