Kendo-angular: A DatePicker is abnormally slow in Edge and IE

[alexeykostevich]

I'm submitting a...

• Bug report

Current behavior

It takes almost 4 seconds to open a DatePicker in Edge and 12 seconds in IE 11.
Occasionally, it is noticeable how a _DatePicker_ repeatedly takes and loses a focus before being expanded.

Scrolling throw months is almost not responsive in IE.

Expected behavior

A _DatePicker_ should provide its functionality without significant delays.

Minimal reproduction of the problem with instructions

+-- @angular/[email protected]
+-- @angular/[email protected]
+-- @angular/[email protected]
+-- @angular/[email protected]
+-- @angular/[email protected]
+-- @angular/[email protected]
+-- @angular/[email protected]
+-- @progress/[email protected]
+-- @progress/[email protected]
+-- @progress/[email protected]
+-- @progress/[email protected]
+-- @progress/[email protected]
+-- @progress/[email protected]
+-- @progress/[email protected]
+-- @progress/[email protected]
+-- @progress/[email protected]
+-- @progress/[email protected]
+-- @progress/[email protected]
+-- @progress/[email protected]
+-- @progress/[email protected]
+-- @progress/[email protected]
+-- @progress/[email protected]
+-- @progress/[email protected]

Browser:

• IE 11
• Edge version 38

System:

• TypeScript version: 2.4.2
• Node version: 6.10.3 (npm 4.6.1)
• Platform: Windows

The issue is not noticeable in Google Chrome or Firefox.

[ggkrustev]

@alexeikostevich, thanks for the detailed report. I noticed that you are using v1.4.0, which introduced many improvements regarding the performance of the component (it become almost twice faster).

Could you double check if that actual version used in the test demo is at least 1.4.0? If it is then could you share a bit more details what your products look like? Would it be possible to share a simple demo that mimics the layout of the problematic page and reproduces the issue?
It will be really hard for us to continue with the investigation when we cannot observe the issue locally.

[alexeykostevich]

@ggkrustev , thank you for looking at this!

I confirm that 1.4.0 is used in the test demo. It behaves slightly better than 1.3.x but still not usable in IE and Edge for some reason.

I understand that it can be extremely difficult to research the issue without a demo. It can take some time to mimic this behaviour but I will try to share a demo shortly.

[ggkrustev]

@alexeikostevich, thanks! Looking forward to review the repro demo soon.

[ggkrustev]

@alexeikostevich, something that is worth noting when it comes to perf improvements is this article.

http://blog.mgechev.com/2017/11/11/faster-angular-applications-onpush-change-detection-immutable-part-1/

My assumption is that the app change detection (executed when NgZone.run is called) is somewhat slow in your case. I suppose that you can try to apply some of the suggestion give in the article if you haven't done some far. This checklist is also worth noting

https://github.com/mgechev/angular-performance-checklist

[alexeykostevich]

Thank you for sharing, @ggkrustev ! This is definitely the way to improve the overall performance for us.

Sorry for the late response: I have just finished my research. Trying to reproduce the issue in a demo app, I found out the root cause.

It seems that there is nothing wrong with _Kendo UI DatePicker_. It behaves slightly slow in IE, but this is natural for so old browser.

The performance issue starts degrading dramatically when I add a CSS library based on attribute selectors. Surprisingly, just having many attribute selectors in CSS regardless of their usages, kills rendering performance in IE: https://medium.com/@antipov.alexei/ie11-performance-bottleneck-de304569361d

This is especially visible in _DatePicker_ because it renders a lot of HTML dynamically. Removing the library, improves _DatePicker_ performance from 11s to 1-2s.

I apologize for submitting the issue. We can safely close it. Hopefully, this finding can be helpful for someone else.

Thank you for looking at this!

[ggkrustev]

Hi @alexeikostevich, indeed, nice finding! I hope that the shared details will help others with similar issues. I will close the thread as resolved.