0 Comments

In this first installment of performance tuning tricks for ASP.NET and IIS 7 we will look at some of the easy, yet powerful possibilities in the web.config file. By taking advantage of these few tricks we can increase the performance of any new or existing website without changing anything but the web.config file.

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

HTTP compression

You’ve always been able to perform HTTP compression in ASP.NET by using third-party libraries or own custom built ones. With IIS 7 you can now throw that away and utilize the build-in compression available from the web.config. Add the following line to enable HTTP compression:

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

By default, only text based content types are compressed.

doDynamicCompression

Setting this attribute to true enables compression of dynamically generated content such as pages, views, handlers. There really aren’t any reasons not to enable this.

doStaticCompression

This attribute allows you to decide whether or not you want static files such as stylesheets and script files to be compressed. Images and other non-text content types will not be compressed by default. This is also something you want to enable.

dynamicCompressionBeforeCache

If you do output caching from within your ASP.NET website, you can tell IIS 7 to compress the output before putting it into cache. Only if you do some custom output caching you might run into issues with setting this to true. Try it and test it. If your website works with this enabled, then you definitely want to keep it enabled.

Tip

By default, only text based content types are compressed. That means if you send application/x-javascript as content type, you should change it to text/javascript. If you use some custom modules in your website, then you might experience conflicts with the IIS 7 compression feature.

Resources

Cache static files

To speed up the load time for the visitors, it is crucial that everything that can be cached by the browser IS cached by the browser. That includes static files such as images, stylesheets and script files. By letting the browser cache all these files means it doesn’t need to request them again for the duration of the cache period. That saves you and your visitors a lot of bandwidth and makes the page load faster. A well primed browser cache also triggers the load and DOMContentLoaded event sooner.

By adding this snippet to your web.config, all static files are cached in the browser for 1 year:

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

This setting sets the expiration date of the file one year in the future. It does that by setting an HTTP header that instruct the browser to add the file to its internal cache. If you hit F5 or ctrl-F5, the browser will request the files no matter what the expiration is set to.

A major problem with client-side caching is if your static files change before the cache expires. Then the visitor with the old version in the cache won’t see the new file until she clears the browser cache or hit F5. Therefore, this setting must be used with caution and probably with a shorter expiration time. In part 2 of this series I’ll address this problem and provide a simple solution to it.

Tip

Make sure that user sensitive information isn't cached on the browser. It will then be available by anyone else using the same browser.

Resources

7 Comments

I recently had to come up with a good argument for upgrading a Windows Server 2003 to Windows 2008 R2. It is used as a web server, so the benefit I was looking for was the upgrade of IIS 6 to IIS 7.5.

So I thought, why not make two deploys of the exact same website to both server editions and compare the performance. It so happens to be that there are many performance comparison articles about this floating around, but no one addressed the client-side aspect of the performance differences.

I’d already prepared the <system.webServer> section of the web.config with various performance tricks for IIS 7. Of course, IIS 6 ignores the <system.webServer> section and therefore don’t get any of the performance enhancements.

I’ve recorded the performance using YSlowand here is what the result looks like:

IIS 6 vs. IIS 7
Click for larger image

The reason for the slightly different file sizes is due to the compression level of the native IIS 7 compression and my custom compression library. The interesting part is when the browser’s cache is primed. That means when the visitor has visited the website before.

It should be noted that it is indeed possible to achieve the same performance metrics using IIS 6, but then you either need to add custom HTTP handlers or write to the IIS 6 metabase.

Here are the performance optimization tricks I used.

1 Comments

I’ve used Google’s Page Speed plug-in for Firebug a lot since it was released last year. Even though it’s not as good as Yahoo’s YSlow plug-in, it’s still very usable for some scenarios YSlow doesn’t support – my favorite being the analysis of unused CSS and selector optimizations.

It also has a feature that will tell you how much your web page will gain by minifying the HTML.

Not only does it analyze the difference but it can also generate an optimized version of your HTML. It removes unnecessary whitespace which in most cases are pretty harmless. But, it does more than that. It actually strips out attribute quotes from the HTML elements as well as remove the closing </body> and </html> tags. This renders the entire page invalid according to any WC3 (X)HTML standards. 

Even though it is a good idea to minify your HTML, this feature of the Page Speed plug-in makes it completely useless to me. Unless you’re Google, Twitter or Facebook, this feature is just strange.

0 Comments

At the Mix10 conference, the Windows Phone 7 teams had some very big announcements – a lot of it had been kept secret and first revealed to the public now. There is however still some details they keep secret. Some of these secrets are the user agents of Internet Explorer for Windows Phone 7, which they simply wouldn’t give us.

After playing with Windows Phone 7 we managed to secure a copy of the user agent string. The user agent for IE on Windows Phone 7 running on the Asus Galaxy device is:

Mozilla/4.0 (compatible; MSIE 7.0; Windows Phone OS 7.0; Trident/3.1; IEMobile/7.0) Asus;Galaxy6


Notice that it identifies the browser as IE7 and the operating system as Windows Phone OS 7. The IE team told us that the browser in Windows Phone 7 is a mobile version of IE7 with certain features ported from IE8. So it doesn’t use the full Trident 4 layout engine that IE8 uses, but instead Trident version 3.1 with a few extra capabilities.

The user agent was retrieved from server logs, so it is the actual user agent from the actual browser.

0 Comments

A few weeks back i found out that the method I use to minify CSS was about 5% more efficient than the YUI Compressor. I tweeted about it and was encouraged to post the code that does the actual minification.

public static string RemoveWhiteSpaceFromStylesheets(string body)

{

  body = Regex.Replace(body, @"[a-zA-Z]+#", "#");

  body = Regex.Replace(body, @"[\n\r]+\s*", string.Empty);

  body = Regex.Replace(body, @"\s+", " ");

  body = Regex.Replace(body, @"\s?([:,;{}])\s?", "$1");

  body = body.Replace(";}", "}");

  body = Regex.Replace(body, @"([\s:]0)(px|pt|%|em)", "$1");

 

  // Remove comments from CSS

  body = Regex.Replace(body, @"/\*[\d\D]*?\*/", string.Empty);

 

  return body;

}

 

The method takes a string of CSS and returns a minified version of it. The method have been modified for demo purposes, so you might want to optimize the code yourself.