Performance tuning for ASP.NET. Part 1

Original author: Mads Kristensen
  • Transfer
Untitled-1In the first part of performance tricks for ASP.NET and IIS7, we will look at some simple, but nonetheless 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 of 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 it all and use the built-in compressor available with 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 get compression for such dynamically generated data as pages, views, handlers. Nothing prevents it from being done.

doStaticCompression


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

dynamicCompressionBeforeCache


If you are caching page output on ASP.NET sites, then you can ask IIS7 to compress the result before caching it. Problems can only occur 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 text 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 maybe you will have conflicts with IIS7 compression.

Resources


Static File Caching


To increase the download speed, it is important that everything that can be cached by the browser is cached by the browser. This includes static files such as images, styles, scripts. By allowing the browser to cache all of these files, it does not have to request them again during the cache period. This saves a lot of traffic to you and your visitors, making page loading faster. A properly configured primary browser cache will trigger the 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 expiration date of the files one year in advance. This happens when IIS specifies in the HTTP header the instructions for the browser, in this case it asks to add the file to the cache. If you press F5 or Ctrl + F5, the browser will request files regardless of their expiration date.

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

The note


Make sure that important user data is not cached by the browser. Otherwise, they will be available to other users using this browser.

Resources


Also popular now: