Performance tuning for ASP.NET. Part 1

In the first part of the performance tricks for ASP.NET and IIS7, we will look at some simple but nevertheless powerful features of the web.config file. Using some tricks we will increase the performance of any new or existing website without changing anything except the web.config file.

The following XML snippets should be placed in the <system.webServer> section in the web.config.

HTTP compression

In practice, you can usually configure HTTP compression in ASP.NET using third-party or native libraries. With IIS7, you can drop all of this and use the built-in compressor available from web.config. Add the following line of code to enable HTTP compression:

< urlCompression doDynamicCompression ="true" doStaticCompression ="true" dynamicCompressionBeforeCache ="true" />

By default, only text data types can be compressed.

doDynamicCompression

Set this attribute to true and you will receive compression for dynamically generated data such as pages, views, handlers. Nothing prevents this from happening.
')

doStaticCompression

This attribute allows you to choose whether or not to compress static files: styles and scripts. Images and other non-textual data are not compressed by default. I advise you to enable this option.

dynamicCompressionBeforeCache

If you do caching output pages in ASP.NET sites, then you can ask IIS7 to compress the result before putting it into the cache. Problems can arise only if you have your own output caching mechanism. Try to activate this feature and test the application. If everything works fine, then why not leave it on?

The note

By default, only textual content types are compressed. This means that if you send application / x-javascript as a content type, then you should change it to text / javascript. If you use your own modules on sites, then you may have conflicts with IIS7 compression.

Resources

Caching static files

To increase download speed, it is important that everything that could be cached by the browser is cached by the browser. This includes such static files as images, styles, scripts. Allowing the browser to cache all these files will not have to re-request them during the cache period. It saves a lot of traffic to you and your visitors, making page load faster. A properly configured primary browser cache will trigger load and DOMContentLoaded events much faster.

By adding this snippet to your web.config, all static files will be cached by the browser for a year:

< staticContent > < clientCache cacheControlMode ="UseMaxAge" cacheControlMaxAge ="365.00:00:00" /> </ staticContent >

These settings set the shelf life of files one year in advance. This happens when IIS specifies in the HTTP header information for the browser, in this case, it asks for the file to be added to the cache. If you press F5 or Ctrl + F5, the browser will request files regardless of their expiration date.

The main problem of caching on the client side is changing static files before the expiration date. The visitor with the old version in the cache will not see the new files until it clears the browser cache by pressing F5. Therefore, these settings should be used with caution and, I think, should be reduced shelf life. In the second part, I will consider this problem and offer a simple way to solve it.