Dan, are you running WebUI Studio 2009?

There are two ways you can reduce the footprint for slower connections:

1. If you're using WebUI Studio 2009 already, you can take advantage of the new compression filter which is designed for SmartWebResources feature. Make sure SmartWebResources is enabled (which loads scripts from ISRes.axd instead of physical file), then simply add one line to your web.config:
   
   

   <add key="ISNet.WebUI.ISRes_Compressed" value="true" />
   

   With the simple line above, the scripts will be automatically compressed using gzip or deflate encoding depending on the browser capability (most browsers today accept both gzip and deflate encoding).
   
   With compression enabled, the overall footprint size for scripts can be reduced by 80%. This will dramatically improve the application speed especially in slower connections. 
   
   

2. If you're not using WebUI Studio 2009 yet, or if you don't use SmartWebResources, but you used IIS 7 (Windows 2008) to host your applications, you can use IIS 7's built-in compression. Similar to our compression model, IIS 7 will then automatically compress your scripts depending on the browser capabilities.
   
   To learn more on how to configure IIS 7 compression, please refer to Configuring HTTP Compression in IIS 7.
   
   

Hope this helps. Let me know if the solutions above worked for you.

I was glad to hear about the new compression feature as IIS compression is not an option for us. Based on your recomendation, we purchased the 2009 ASP.NET Suite.

My problem is:

1. I can find absolutely no documentation on this feature. In fact, we found very little documentation at all about the web.config options that are available and how they interact. For example, can this compression setting be used in conjunction with XMLCompression or the CSS options? Are these cumulative or competitive? What affect do they have on the CPU and memory requirements for the server or client system?

2. The "Deployment Manager" tool doesn't have an option for this new compression feature. In fact, this tool itself is also very poorly documented. 

3. Putting the line you suggested into the most logical location in the web.config file did not result in any change in the overal footprint size.

I tested this with the latest version of Safari (which is documented to support both kinds of compression) and looked at the Web Inspector tool for a page that has a grid, combo, web dialog box, and web imput. Between the JavaScript and the object definitions in HTML the page took up nearly 1.5 MB!! I compared with and without this setting and compared the 2008 version of the grid to 2009. Not only was there no improvement, but the footprint size actually went up.

I need to see a sample of how to implement this new compression feature.

What is the expected javascript footprint for a page that uses all four of these features: grid, combo, web dialog box, and web imput?

We purchased the latest version of the grid specifically because of this new compression feature and we need to have it work for us.

Dan, thanks for your response.

Here are the answers to your questions:

1. Yes, this feature is actually a late-breaking enhancement that we added in 2009 release. We plan to cover some of the new late-breaking features through interactive medias such as blogs and community, and then sum them up in the next release's documentation.
   
   Here are some details for the compression feature:
• This feature can be used together with other settings such as Xml Compression and CSS Compression.  
• This feature works in conjunction with SmartWebResources feature. So, make sure you have configured SmartWebResources properly. Click here to learn how to configure SmartWebResources, and here to ensure it's working.
• When enabled, it used server-side resources to perform the compression. It does use a bit of the server-side CPU processing and memory for the compression. But our testing indicates the resources usage is still under acceptable range with decent performance.
• As for the client-side, the performance and memory usage is almost not noticable since the compression feature is built natively in the browser.


2. The Deployment Manager documentation can be found here.
3. I'm not quite sure if you can see the compression results in the Safari browser without external plug-in, although I'm pretty sure Safari has supported gzip compression since its earlier version. However, you can check the compression results using IE7 or IE8, or Firefox browsers. When using IE, make sure you have HttpWatch installed in your development machine.
   
   The following screenshot shows how the compression results look like when you're using IE and HttpWatch. Notice on the red-highlighted shape for the compression results.
   
    
   
   

What is the expected javascript footprint for a page that uses all four of these features: grid, combo, web dialog box, and web imput?

We purchased the latest version of the grid specifically because of this new compression feature and we need to have it work for us.

 A note regarding the compression level, the SmartWebResources compression feature used medium compression level to have a good balance between output and performance.

In most cases (and per my inspection on each compressed script), the average compression is at 75% level. That means, if the total size of uncompressed scripts is 1.5MB, then you can expect the total size after compression to be approximately 375 - 400 KB.

Please let me know how you find the results at your end. 

Here is what we found using IE 8:

1. Setting the value of ISRes_Compressed to true or false didn't matter. If the line was in the web.config file then the compression was on.

2. It wasn't clear from the initial description, but combining IIS compression and ISRes_Commpressed produces no benefits in terms of the JavaScript. Although, IIS dynamic compression can shrink the size of the ASPX page.

3. There are a number of cases where the same JavaScript is downloaded twice. It looks like this is because the capitalization of the file names changed.

Is there any way to pre-load the JavaScript or somehow keep it (semi) perminantly cached on the client? Because of the way our application works we can't just set the cache expiration policy that way for the entire ASPX page.

Dan, thanks for sharing your results. It's great to see the compression worked at 72% level for you.

Several points for your questions:

• The ISRes_Compressed variable is cached internally for performance reason. So it may have no effect after you set it to false without restarting the application pool. However, you should still use the "true" value to ensure it works across application restarts.
• IIS Compression checks for the response filter when ASP.NET passed the final output stream to the IIS 7 handler. When IIS 7 detected that the response is already compressed, it won't go for another compression to avoid redundant compression. Smart logic.
• The duplicate javascript requests is due to the different version being requested, not because of the capitalization. For example, notice that WebAnimation.js is requested twice, one is for version 2.5, and another is for version 3.0. The number behind the request name indicates its requested version.
  
  That said, could you ensure that you have used all 2009 products? eg, use WebDesktop 3 assemblies instead of 2.5? If you've used all latest products and there are still request for version 2.5, then we will investigate it at our product level.

Another interesting point regarding Javascript caching: SmartWebResources will automatically cache the javascript and other resources in the client browsers when your application is running in the production server (eg, compilation debug="false" in web.config). So the answer is yes, and it's automatic, so there're no efforts needed at your end for the caching.

The built-in cache setting sets the expiration to occur when the files are modified since last access (based on modified date of each resource).

Let me know if you have other questions. Thanks!

The development machine running this example has the older version installed, but the only files in the bin folder (these are not referenced rather they are physically located in the bin folder) are the 2009 versions. The CommonLibrary folder is not included and is not aliased. the web.config file has not reference to the older versions.

The duplicate JavaScript entries were:

ISRes.axd?F/CoreValidator.js/305000701

ISRes.axd?F/corevalidator.js/305000701

and

ISRes.axd?F/CultureInfo.js/305000701

ISRes.axd?F/cultureinfo.js/305000701

Note that they have the same number attached!

Hi Dan,

Thanks for following up on this duplicate issue.

We've found the issue which appears to be in WebInput, and has been resolved. The fix will be available in upcoming service pack.