Hi
My biggest problem with IG controls it's huge amount of js files been transferred to client.
With Aikido the things even worse.
I have 14!!! ig js files + 2ms ajax.(And we don't getting to edit functionality of grid yet).
With sites having long roundtrip such grid will definitely bee a problem.
Thanks.
Hi Anatoly,
Hi.
You see, it's not all about js size but on count of js files.
Browser will check for every js it's version, since it's not parallel process(only two on time) it will reduce page load time.
Consider pack all js into one and compress it.
It's better to use one file of 200 k then 10 of 2
Thanks
Here: http://weblogs.asp.net/scottgu/archive/2007/06/08/new-asp-net-ajax-control-toolkit-release.aspx
Scott Guthrie talks about new addition to AJAX toolkit called ToolkitScriptCombiner control.
Take a look on this one.
Please do keep files sizes and numbers to a minimum. I've experienced Anatoly's problem first hand. I was in Tel Aviv earlier this year and was showing one our applications to our customer and it was slow. The vast majority of my customers are accessing my sites from overseas so keeping things as lean and fast is a high priority for me.
1) The app is running in release mode.
2) Slowness of page loading appears every hit on the same page.
There are many articles on this issue. Example:
http://www.die.net/musings/page_load_time/ with this:
Load fewer external objects. Due to request overhead, one bigger file just loads faster than two smaller ones half its size. Figure out how to globally reference the same one or two javascript files and one or two external stylesheets instead of many; if you have more, try preprocessing them when you publish them. If your UI uses dozens of tiny GIFs all over the place, consider switching to a much cleaner CSS-based design which probably won't need so many images. Or load all of your common UI images in one request using a technique called "CSS sprites".
Or this one:
http://rakaz.nl/item/make_your_pages_load_faster_by_combining_and_compressing_javascript_and_css_files
That's exactly how it's supposed to happen. In Anatoly's case, it sounds like something else must be causing the slowdown. It's possible that extremely slow disk access is causing problems with the cached version of the JS resource. It could also be that an overutilized server is experiencing large levels of latency when esablishing connections - hence making the overhead to download a file far exceed the time to download the content. Either way, as Joe mentioned above, we will be looking at providing a solution which compiles many of the separate scripts into a single common file, which should help in Anatoly's case.
Isn't this only a hit the first page load? After that, the javascript files are cached on the client, and shouldn't need to be reloaded on subsequent requests (unless your app is running debug mode, which if it is will disable client caching of JS files). The only hit you should see would be the check to see if it needs to download the file, which shouldn't result in 35-45 seconds of time.