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.
Zack
Head over to www.nikhik.net and grab the Web Development helper, its free. When you have it running head to www.infragistics.com.
You will see a lot of traffic. Double click on any of the webResource.axd. Then click on the 'Response Content' tab. You will see the data that is being sent
Here is a sample of what you will see.
/* * Infragistics WebNavigator CSOM Script: ig_webmenux.js * Version 7.3.20073.38 * Copyright(c) 2001-2006 Infragistics, Inc. All Rights Reserved. */ etc lots of stuff
As you can see this is the javascript that supports the webmenu. Here is a link from MS that has more info on it.
http://support.microsoft.com/kb/910442
Zack:
WebResource.axd is simply an HttpHandler that ASP.NET uses to reach into our assemblies to grab embedded resources like JavaScript files or images. This feature of ASP.NET, added in 2.0, is what allows you to not have to deploy all of the JavaScript files to your server since they are all already embedded in the assembly.
When ASP.NET renders a page with our controls on it, our control tells ASP.NET what script and image resources it needs, and that they are embedded in our assemblies. As a result, ASP.NET renders the resources URLs using the WebResource.axd handler. As part of the WebResource.axd URL, ASP.NET appends a bunch of querystring stuff that the handler uses to determine not only specifically which resource in our assembly to grab, but also a timedate stamp that correlates to the assembly version. So in reality the webpage has something like this in it:
/WebResource.axd?d=RkTKYb30579LZf3nYSUNBcrHOzJQoIwTkY2nCufoJKGUmhQ97WEfKBXm26XVqWSOfyG3GCv5SkfuAVa3sQmCOf34xkWmH2YWaFqDL8veU7Oi9AkXR95FSAD8WG9U26H7aD-pU2Y28FlWmtdhrnqB6A2&t=633277870140000000
In this querystring the value of "d" is the specific resource that should be returned (in this case I grabbed a URL that should return a JS file). The value is an encoded string that contains the assembly name, fully-qualified namespace and name of the embedded resource. This should always be a constant value as long as those pieces of data stay the same in the assembly.
Also notice the "t" value in the querystring. This is a timestamp that, if I recall correctly, is tied to the timestamp of the assembly that contains the resource.
So when the browser sees a URL like this it makes the request for it just like it would for any other resource (eg "/images/foo.gif" ). The request is handled by the HttpHandler and some embedded resource from the assembly returned to the browser. The resource returned might be a script file, it might be an image, but regardless, just like every other HTTP request that the browser makes, it will cache the results of that request and the next time a request for that same URL is made, it will try to use the cached version first. In this case, unless you update the assembly with a new version, the timestamp should remain the same, or change the assembly name, namespace or resource name, the URL will never change and therefore the browser will use the cached version of the resource.
Hope that helps.
Devin
Tony,
I'm confused, as usual You said the webresource.axd file could hold various things (image, JavaScript file, etc) so how can we expect this to be cached? Seems to me if the contents vary as you state there's no way to cache it, unless multiple copies of the file are cached.
Here's another link for improving download speeds and web application performance:
http://developer.yahoo.com/performance/rules.html
The number one way to improve performance that they mentioned is to minimize HTTP requests or in others words to minimize the number of linked files on each HTML document. It is better to have a single, large file that contains all of the Javascript that is needed than multiple smaller ones. This is because of the overhead that is involved when making a request for another file.
So, please, when reducing the size of the JS files, please also reduce the number of files that are included. Thanks!
Thank you for your reply.
I do appreciate your answer and the merits of NetAdvantage. If I were developing apps for a company intranet then the additional benefits of a rich user environment would be extremely valuable.
Also, if all of my users on the web had high speed broadband ( and this is improving all the time) then I would also be able to handle the increased traffic.
Yet, there are still those out there with dialup, and yes maybe they should be put out of their misery and denied internet access completely.
For the first two groups I may be able to handle 200Kb/page for some pages, but again it is not just line speed that concerns us here, there can be considerable bandwdth costs incurred for high traffic sites.
I am sure that the developers are working hard to get the best balance between rich user experiences and optimum footprint. Yet as the technology improves so do our resource requirements.
Who was it that said 640K should be enough memory for anyone?