This is a migrated thread and some comments may be shown as answers.

Why does telerik perform terrible with IE?

25 Answers 772 Views

Scheduler

This is a migrated thread and some comments may be shown as answers.

Bryan McFarland asked on 11 Feb 2010, 12:52 PM

Hi Guys,

One of our developers has been using the telerik controls such as the scheduler, tab strip, etc. for several months now. Most of our customers use IE7/IE8. And, we see a definite performance decrease when using any telerik controls with those browsers. In FireFox, the performance appears better.

It has gotten to the point where my developer is going to pull the telerik controls from our product and go to other 3rd-party tools because the customers are complaining about the sluggish performance. Granted, some customers have weak client computers while others have top-of-the-line. In almost all cases, the telerik controls perform terrible in IE.

I know Microsoft's browsers may have issues that FireFox does not, but IE is not going anywhere, and something must be done to support it better.

My developer has looked at the top 10 list for increasing telerik performance, and we have tried everything to trim down the code supporting the telerik controls to make them function lean, mean, and fast. But, this still has not given us the performance that we expect.

Even when using the live demos at telerik of the scheduler, the demos work better on FireFox, etc. than in IE. Something must be done to correct this. Again, IE is not going anywhere.

If you have any betas, coding suggestions, etc., I would gladly welcome them. Until a fix is available for performance, I cannot afford to keep using telerik in the future.

Bryan
:-(

25 Answers, 1 is accepted

answered on 11 Feb 2010, 08:24 PM

I agree as well. The scheduler is one of the worst offenders in the lot. It runs terrific in FF and Chrome, but like a dog in IE7/8. So slow it's pratically unusable -- and since a great deal of our client base uses IE, this makes things difficult for us.

We're in the process of debating whether to purchase 7 new full Telerik packages and it's hard for me to recommend Telerik because of performance issues.

Is there anything in the works to improve performance of the scheduler in IE? I don't want to have to spend several hundred dollars per seat just to get a different 3rd party scheduler.

Thanks,

Troy

answered on 12 Feb 2010, 07:54 AM

Hi,

Thank you all for bringing this issue up. Indeed IE7 is one of our biggest concerns when it comes down to performance for practically all controls. Thanks to excellent tools like dynaTrace we're still finding ways to improve the performance there, dramatically in some cases.

We're currently working on optimizing the scheduler skins and this will greatly reduce the browser memory usage in the Q1 release. We've also migrated to jQuery 1.4.1 which should give us a bit of a boost especially when it comes to web service binding.

If you're experiencing performance issues in IE8 then you should check that your page is being rendered in IE8 Standards mode. Rendering in IE7/quirks is much slower.

We'd love to look at any particular scenario that is causing problems for you and profile them.

The general articles on performance can be found here:
http://www.telerik.com/products/aspnet-ajax/resources/top-performance.aspx

Greetings,
Tsvetomir Tsonev
the Telerik team

Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.

answered on 12 Feb 2010, 04:49 PM

Hi Everyone,

Thanks for everyone's input on this. I'm glad that I'm not alone in seeing this issue. It's TERRIBLE! And, it's frustrating for my team because we've put many hours and substantial money into investigating database performance, IIS performance, etc. with no success. And, in the end, it's the telerik controls. And like many of you, we can't afford weeks and weeks into fiddling with the telerik controls hoping something magical will happen. We are going to look for other 3rd party tools that may have a better solution.

Here's a follow-up to this thread. A few of the things I notice in IE7/8 that I don't see FireFox are sluggish hovering over appointments (blank or otherwise) and sluggish performance of right-click menus.

I wish I could turn off hovering of blank appointments and just be able to click a blank appointment and perform an operation like adding a new appointment.

I'm not using JQuery for databinding. So, I that's not going to help me in the future.

The skins are a concern to me. In particular, the client-side javascript events along with CSS concern me in the arena of performance with the telerik controls. Monitoring those events, changing object styles such as in the case of hovering, etc. surely take a processing toll on IE. In fact, when I monitor my task manager, it practically doubles in processor usage for each hover I perform in the scheduler (from 14% to 35% for example). I'm sure others see that too. Maybe FireFox does a better job of managing that. But again, IE, not FireFox is what I have to use for my customers.

As far as IE8 in different modes, I have not see any significant difference in performance.

IE7 has been out for a long time. Years in fact. IE8 has been out for a while. I really think this issue should have been addressed earlier than now and at a higher priority. I have to admit, I am not very confident in telerik having a solution of significance in Q1. But, I hope it does. Their controls have a lot of very nice features. But until then, I can't afford to wait a month or two for a solution. A scheduler is not like a dropdownlist that I can find anywhere. It is a significant key to many projects, and it can make or break a project in many instances.

Bryan McFarland

answered on 16 Feb 2010, 12:51 PM

Hi Bryan,

We appreciate your sincere feedback. Most probably, we will be able to come up with new styling for RadScheduler for Q1 2010 which is very likely to result in improved performance. Note, that the current rendering will remain the same so there will be no breaking changes. Only the css styles will be improved.

If you want to give up the hover effects in exchange for performance gain, you can add the following javascript after your script manager:

<asp:ScriptManager ID="ScriptManager1" runat="server">

</asp:ScriptManager>

<script type="text/javascript">

Telerik.Web.UI.RadScheduler.prototype._onRowMouseOver = function() { }

</script>

I hope this helps.

Regards,
Peter
the Telerik team

answered on 14 Mar 2010, 04:54 PM

I'm really kind of shocked by the poor performance of the scheduling control. If you want examples just try your own demos. An Appointment form takes 3+ seconds to open and a similar time to close (ie and FF). The performance is no better on my local machine (and those of my developers). This is simply not acceptable. The controls have a great look and great flexibility but what good is that if the performance is not there. I'm really dissapointed because I would buy the suite today if they performed better. I really don't want to see references to "Top 10 Performance" boosters b/c the performance on the Telerik demo site is poor (surely these are optimized). I'm also dissapointed by the lack of attention to this. It's hard to understand why improving this wouldn't be a top priority.

Kevin

answered on 18 Mar 2010, 09:37 AM

Hi Kevin,

Yes, the RadScheduler Advanced Edit pop up form is also reloading and initializing the whole RadScheduler underneath it on show and close (postback). If you use the non-modal Advanced Edit form instead of the pop up one, it will be much faster since RadScheduler is not loaded and initialized (this is a current limitation) - you can switch the modal form off with AdvancedForm-Modal="false". We are currently investigating if something can be done to speed up the Advanced Edit pop up, so stay tuned for more.

Best wishes,
Kamen Bundev
the Telerik team

answered on 04 Jun 2010, 07:04 PM

Hi Everyone :-)

I've been monitoring the progress of the Telerik 2010 version of the scheduler. I still have poor performance. Just try the online demos. Again, the simple task of hovering over cells in the schedule is slow in IE as compared to FireFox and Chrome.

Maybe the route to go is finding a good ActiveX scheduling control or a different web-based control. That's the direction I'll be taking.

Until I've found another control, I'm asking my customers to use Google Chrome when using the Telerik scheduler. However, this isn't a great solution at all when the customer has to scan and use other devices that require ActiveX controls. As such, a customer now has to switch between Chrome and IE to do their job, which is terrible. And such tricks as using Chrome Frame, etc. are not the answer from my testing.

So, I don't think I can blame Telerik completely for this problem because IE 6/7/8 have terrible Javascript engines and there is not estimate on IE9 coming out in production. And, Chrome can't take care of my ActiveX requirements very well. I wish there was a way to replace the Javascript engine in IE8 with something else.

This just stinks!!!!

Bryan
:-(

answered on 07 Jun 2010, 02:08 PM

Bryan, is it just the hovering you have a problem with? I've never found that an issue in IE (we have to support IE6), of course I may be not noticing it. We use the Sitefinity skin, if that matters.

What I have found issue with is this: http://www.telerik.com/support/pits.aspx#/public/aspnet-ajax/858

That glosses over the problem a lot but in a nutshell the problem is that in Web Service data binding (a better performing setup for the control IMO) the server control brings back all the appointments for the month even though only 2 appointments per day are visible.

We have some calendars with hourly recurring appointments, so IE is parsing/iterating hundreds upon hundreds of appointments, when only 2 per day (max) are ever rendered. This locks up the browser for minutes.

Have you noticed this too by any chance?

answered on 07 Jun 2010, 05:38 PM

Hi Roatin :-)

On the hovering, I see the problem even on the online demos at www.telerik.com for the scheduler control. You can definitely see the difference when hovering between IE and Chrome or even FireFox. I know it's due to the javascript engine differences between them where IE has the worse performing javascript engine.

And, on another front, I have a customer with about 10 resources and on a daily view, they usually have 100-200 appointments. And, as you can imagine, under IE, the scheduler control is slowwwwwwwwwwww. We must use Chrome to have decient speed. Unfortunately, our customers have to constantly switch between IE and Chrome because they scan, use signature pads, etc. that are ActiveX controls. Ughhhhh!!!!!! LOL!

We've reduced as much as possible the data coming down to the scheduler control, but our scheduler page is still about 600k in download size and the amount of javascript running drags IE down big time.

Bryan
:-(

answered on 10 Jun 2010, 01:13 PM

Hi,

The high CPU load in IE during hovering is indeed a problem. It's caused by the way IE applies the :hover CSS pseudo-class to elements different than <a>. Take these selectors for example:

.myClass:hover { } // Very slow in IE!!!

a.myClass:hover { } // Fast - targets a elements only

The problem is that this doesn't need to be an element in the scheduler itself. Just having the first selector anywhere on the page is enough to bring IE to its knees.

This indeed can be seen in our examples. While the schedule skins are "hover-free", we still haven't had the time to clean-up the styles of the quick-start framework itself.

So it's not the JavaScript to blame, but the CSS performance. No amount of JavaScript optimizations will solve that, but it can be avoided by carefully examining the CSS on your site. Look for hovers that target anything else than anchors.

As for the performance suggestion by Roatin - we still haven't had a chance to implement it. We're getting ready for the Q2 release and we had to prioritize and leave some tasks for after the release.

Sincerely yours,
Tsvetomir Tsonev
the Telerik team

answered on 30 Aug 2012, 07:35 PM

Reviving the old thread, but this is still an issue for us (Telerik version 2011.2.712.35 / IE9)
We have a requirement to display several hundred grouped rows to allow spreadsheet-like data entry. Putting the grid in edit mode pretty much freezes IE9, while FireFox and Chrome perform reasonably. (The recommended Telerik optimization techniques for using Rad Managers and compression make little difference.)
The bulk or IE processing goes into AddEventHandler and OffsetWidth JavaScript functions. Which tells me that this could be solved with IE-specific JavaScript optimization.

Bottom line is that RadGrid is pretty much unusable with large number of rows in IE9.

answered on 08 Jul 2014, 03:33 PM

Bryan and other victims of IE's poor performance,

It's been over 4 years since you first created this post, IE is now at version 11 and UI for ASP.NET AJAX at 2014.2.618.40.

I'm experiencing the same problem you first reported with the RadScheduler performing terribly in IE when there are many appointments, 50 per day. IE is as much as 3X slower that Chrome, Firefox and Safari.

I've invested a lot of development time into creating an application based on Telerik controls that looks great but now having encountered this performance problem I'm questioning whether I need to abandon the RadScheduler and look elsewhere for a better performing control.

I've spent the last two weeks trying every suggestion and more, but have had little luck. I'm now at the breaking point you seemed to be at your first post.

How did you resolve this problem? Any help would be greatly appreciated.

Thanks

Vince

answered on 08 Jul 2014, 05:49 PM

Hi Vince,

We never resolved the issue, but we did a few things to make the RadSchedule bearable.

1) Persuaded users to use Google Chrome (which has one of the fastest JavaScript engines).
2) Reduced as much as possible the amount of data retrieved from the server to populate a RadSchedule. For example, not use tooltips on appointment blocks or eliminating extra JavaScript script for drag-n-dropping of appointment blocks.
3) Educating users to limit columns to what they actually need to view.
4) If a user is required to use IE (for example, scanning using ActiveX controls), then get the user up to the highest version of IE for improved JavaScript engine performance. IE 8 has a terrible JavaScript script engine.

Other than that, not much more we were able to do.

Bryan
:-(

answered on 08 Oct 2014, 06:17 PM

In addition to implementing some of Bryan's suggestions to improve performance, I was able reduce some of the javascript processing to shave off several seconds. I used IE's F12 Profiler to examine where the javascript spent most of it's time. I overrode some of the expensive functions so they didn't do anything.
I discussed this approach with Telerik support and they said there is some overhead in the javascript for compatibility with older browsers. They couldn't endorse my approach, but suggested that I try it with the browsers I am developing for, (IE8+), and see what affected it has. Since I'm desperate for better performance, I eliminated a couple functions I could live without.

Here is the code I insert after the RadScriptManager closing tag.

<script type="text/javascript">

            var $ = $telerik.$,
            $T = Telerik.Web.UI;

            $T.RadScheduler._preInitialize = function () { return; };
//This override creates a slight day of week column misalignment
$T.RadScheduler._adjustContentDimensions = function () { return; }
            $T.RadScheduler.prototype._raiseInit = function () { return; }
        </script>

Vince

answered on 28 Sep 2016, 02:31 PM

Hello John,

Could you. please, explain a bit in detail what bottlenecks in the performance of your app do you face? Which are the Telerik UI for ASP.NET AJAX controls that you use and demonstrate slow response time? Which are the processes that delay the app?

Ideally, you could submit a support ticket, including an isolated runnable sample project, demonstrating the issues observed, so we will be able to troubleshoot it locally and provide you with the most appropriate assistance for your case.

Regards,
Veselin Tsvetanov
Telerik by Progress

Do you need help with upgrading your ASP.NET AJAX, WPF or WinForms projects? Check the Telerik API Analyzer and share your thoughts.