Clarity: Datagrid rendering slow in Internet Explorer 11

[oliverhanappi]

Select one ... (check one with "x")

[x] bug
[ ] feature request
[ ] enhancement

Expected behavior

The datagrid should render in Internet Explorer 11 as quickly as in Chrome:

Chrome Performance:

Actual behavior

The datagrid renders comparatively slow in contrast to pure HTML tables in Internet Explorer 11 for moderately sized grids (10 columns, 50 rows). There is a noticable delay when opening a page containing such a datagrid.

Internet Explorer 11 Performance

Reproduction of behavior

https://plnkr.co/DuPym0jJHmpDx9sF7mPI

Environment details

• Clarity version: 0.10
• Browser: IE 11

[mathisscott]

@youdz ^

[youdz]

So I looked at this quickly, and it's very hard to pinpoint the issue and figure out what we can do about it. This is going to require intensive investigation in IE11, which is never quick and easy.

Of course rendering a full-blown datagrid is going to take longer than a table because column width are dynamic (CSS-specified column width, user-controlled column width through splitters, ...), so we have to go over each cell to size it accordingly. Just trying in Chrome and raising the numbers also shows a significant time difference.
Also note that our datagrid is not a table, because browsers do not let you do anything advanced with table layouts (animations, sticky parts when scrolling, ...). To address this in the cleanest way possible, our datagrid is written with a flexbox layout, which might not be as render-optimized in older browsers.

So far the performance of datagrid has always been enough, and we have always addressed slowdowns as fast as we could. This issue is in the same situation, but the fact that it's exacerbated by IE11 as opposed to other browsers is going to make it much harder to work through. By that, I mean that other browsers start taking too much time to render the datagrid by the time you should really be using pagination. For IE11, it slows down a little too early where there could still be valid use cases without pagination.

I'm adding this to our backlog and we'll assign it for more in-depth investigation during our planning sessions. Thank you for reporting the issue. 👍

[choutkoa]

Is this issue planed to be fixed any time soon?

[mathisscott]

@choutkoa
this is an issue we would need to spend a non-trivial amount of time investigating. I've marked it so we will come back to it and determine when or if we can fit a deep dive into the problem into our schedule.

[choutkoa]

Any news on this?

[choutkoa]

Do you have any news on this, I noticed you removed some labels

[mathisscott]

HI @choutkoa
Unfortunately, this is an issue that always falls lower in priority for us due to declining IE11 usage. Does your application deviate from this industry trend significantly?

[krzychuwr1]

I have the same issue, our customer's users are using IE11 (it's an internal application). I would appreciate it if you can find some time to optimize grid performance on IE11

[siddharth1903]

+1 . Our clients are also using IE11 , since its an internal portal app. Since IE11 is officially a supported web browser for the framework, would request prioritization of the issue. The same is observed with clr v2 as well

[gnomeontherun]

Due to IE11 being EOL soon, we're not able to invest in major improvements. The Datagrid is certainly more complex to render than a table, so that is expected. With issues that are real bugs, we are able to investigate and triage, but for optimizations at this stage it is not something we are able to spend time on.

Our recommendation is to simplify the use of the Datagrid, use pagination, and be considerate of the volume of components and complexity of the application that Angular has to render.

Closing as something we're not able to take action on.

[siddharth1903]

@gnomeontherun I guess IE11's End of support comes somewhere at 2025. The data grid hangs for even showing 20 records at once. We do use pagination at 20 today and Use On push.

[sayanbanerjee87]

@gnomeontherun IE11 support ends with windows 10 which is around 14th October 2025 please refer this link, https://github.com/SAP/openui5/issues/1697
B2B app specially in banking domain IE11 is still widely used. There data-grid is an extensively used component. This performance lag totally hampers user experience. Moreover I didn't find this kind of recommendation like IE11 can't be used due to this kind of performance issues in clarity's any of the documentation. Our client uses IE11 and it has become headache to convince them about this behaviour.

[siddharth1903]

I also don't think this Comes under the optimization bracket, since the rendering behaviour is bugged and is not on par with other supported browsers... Possible to revisit the priority here? @gnomeontherun

[gayathrirajendran]

Datagrid being a prominent UX design pattern, web applications have important information rendered using clr-datagrid. Enterprises continue to largely use Windows that ship with IE11 default, expecting all applications to atleast render without huge delays and 5 years is no small time.
@gnomeontherun can this be considered for resolution ?

[gnomeontherun]

Performance in IE11 is a big request, but we have to be clear about what the return on the investment here. If we can improve 10% (which is about as much as I'd expect given the complexity of the Datagrid and Angular), it wouldn't make a major difference in a 5 second rendering delay. I must emphasize that there are limits to what we can do in this arena, especially as we add new features (which can also cause more complexity). I also expect it might take months to squeak out a 10% boost, which is my largest concern because it would delay other important work.

Regardless of the experience from Clarity, IE11 users experience poor performance overall compared to other browsers, and machine type makes a significant difference as well. We cannot expect IE11 to be as fast as Chrome or Firefox in 2020. We also have subjective perspectives on what is acceptable lag or not, and is it even possible to provide the same application to IE11 and expect a similar experience from Chrome/Firefox. Microsoft considers IE11 a compatibility solution, not a performance solution.

So what to do?

First, If the behavior is buggy (as in not working), then please do open a separate issue for that issue with a reproduction. We will be happy to investigate those broken issues. _Please provide an isolated reproduction._

Second, If the behavior is uncharacteristically slow (as in working but significant lag), please try to create a reproduction outside of your application. Many of the performance issues mentioned here are difficult to triage or understand without isolated reproductions of _just the datagrid_. If you can reproduce something that has significant lag in IE11 but shouldn't (something like a 5 column datagrid with 20 rows), then please submit a new issue for it.

Finally, let me suggest a few more optimizations that you might be able to make on your end.

1. Use server-driven datagrid instead of 'smart' datagrid. If you load a large dataset into the page and have it paginate client side, this is more difficult than having a smaller set that your server provides.
2. Don't use components inside of Datagrid, use it plainly. In other words, don't try to wrap rows inside of reusable components (added complexity), add custom components inside of cells (especially components that have bindings), or other abstractions that complicate the rendering cycle of the Datagrid.
3. Reduce features used in the Datagrid (do you need sorting enabled? do you need filters?).
4. Review what else is on the page and simplify. Can something be moved or removed? Are you polling a server or running things continuously? Are you live refreshing data, and do you need to?
5. Profile your application and see for sure what scripts are consuming large amounts of resources. It may be Clarity, it may not.
6. Last resort option, but worth considering if IE11 performance is a key goal for your application, is to change to a table for IE11 or offer users of IE11 a different experience that can be rendered more quickly.

In summary, it is very difficult to prioritize IE11 without very specific issues to isolate and triage. We want to fix broken behaviors in IE11, but performance is very difficult to triage. We need _isolated reproductions_ of issues to dig deeper.

I'm going to lock this thread, but emphasize that if you can provide updated and isolated reproductions, especially if the behavior is broken, we'll be better able to triage and investigate options.