Making best use of cache for high performance website

Use URLs consistently

Browsers cache content based on the URL. When URL changes, browser fetches a new version from origin server. URL can be changed by changing the query string parameters. For example, “/default.aspx” is cached on the browser. If you request “/default.aspx?123” it will fetch new content from server. Response from the new URL can also be cached in browser if you return proper caching headers. In that case, changing the query parameter to something else like “/default.aspx?456” will return new content from server. So, you need to make sure you use URL consistently everywhere when you want to get cached response. From homepage, if you have requested a file with URL “/welcome.gif”, make sure from another page you request the same file using the same URL. One common mistake is to sometimes omit the “www” subdomain from the url. www.pageflakes.com/default.aspx is not same as pageflakes.com/default.aspx. Both will be cached separately.

Cache static content for longer period

Static files can be cached for longer period like one month. If you are thinking that you should cache for couple of days so that when you change the file, users will pick it up sooner, you’re mistaken. If you update a file which was cached by Expires header, new users will immediately get the new file while old users will see the old content until it expires on their browser. So, as long as you are using Expires header to cache static files, you should use as high value as possible.

For example, if you have set expires header to cache a file for three days, one user will get the file today and store it in cache for next three days. Another user will get the file tomorrow and cache it for three days after tomorrow. If you change the file on the day after tomorrow, the first user will see it on fourth day and the second user will see it on fifth day. So, different users will see different versions of the file. As a result, it does not help setting a lower value assuming all users will pick up the latest file soon. You will have to change the url of the file in order to ensure everyone gets the exact same file immediately.

You can setup Expires header from static files from IIS Manager. You’ll learn how to do it in later section.

Use cache friendly folder structure

Store cached content under a common folder. For example, store all images of your site under the “/static” folder instead of storing images separately under different subfolders. This will help you use consistent URL throughout the site because from anywhere you can use “/static/images/somefile.gif”. Later on, we will learn it’s easier to move to a Content Delivery Network when you have static cacheable files under a common root folder.

Reuse common graphics files

Sometimes we put common graphics files under several virtual directories so that we can write smaller paths. For example, say you have indicator.gif in root folder, some subfolders and under CSS folder. You did it because you need not worry about paths from different places and you could just use the file name as relative URL. This does not help in caching. Each copy of the file is cached in browser separately. So, you should collect all graphics files in the whole solution and put them under the same root “static” folder after eliminating duplicates and use the same URL from all the pages and CSS files.

Change file name when you want to expire cache

When you want a static file to be changed, don’t just update the file because it’s already cached in user’s browser. You need to change the file name and update all references everywhere so that browser downloads the new file. You can also store the file names in database or configuration files and use data binding to generate the URL dynamically. This way you can change the URL from one place and have the whole site receive the change immediately.

Use a version number while accessing static files

If you do not want to clutter your static folder with multiple copies of the same file, you can use query string to differentiate versions of same file. For example, a GIF can be accessed with a dummy query string like “/static/images/indicator.gif?v=1”. When you change the indicator.gif, you can overwrite the same file and then update all references to the file to “/static/images/indicator.gif?v=2”. This way you can keep changing the same file again and again and just update the references to access the graphics using the new version number.

Store cacheable files in a different domain

It’s always a good idea to put static contents in a different domain. First of all, browser can open another two concurrent connections to download the static files. Another benefit is that you don’t need to send the cookies to the static files. When you put the static files on the same domain as your web application, browser sends all the ASP.NET cookies and all other cookies that your web application is producing. This makes the request headers be unnecessarily large and waste bandwidth. You don’t need to send these cookies to access the static files. So, if you put the static files in a different domain, those cookies will not be sent. For example, put your static files in www.staticcontent.com domain while your website is running on www.dropthings.com. The other domain does not need to be a completely different web site. It can just be an alias and share the same web application path.

SSL is not cached, so minimize SSL use

Any content that is served over SSL is not cached. So, you need to put static content outside SSL. Moreover, you should try limiting SSL to only secure pages like Login page or Payment page. Rest of the site should be outside SSL over regular HTTP. SSL encrypts request and response and thus puts extra load on server. Encrypted content is also larger than the original content and thus takes more bandwidth.

HTTP POST requests are never cached

Cache only happens for HTTP GET requests. HTTP POST requests are never cached. So, any kind of AJAX call you want to make cacheable, it needs to be HTTP GET enabled.

Generate Content-Length response header

When you are dynamically serving content via web service calls or HTTP handlers, make sure you emit Content-Length header. Browsers have several optimizations for downloading contents faster when it knows how many bytes to download from the response by looking at the Content-Length header. Browsers can use persisted connections more effectively when this header is present. This saves browser from opening a new connection for each request. When there’s no Content-Length header, browser doesn’t know how many bytes it’s going to receive from the server and thus keeps the connection open as long as it gets bytes delivered from the server until the connection closes. So, you miss the benefit of Persisted Connections that can greatly reduce download time of several small files like css, javascripts, and images.

How to configure static content caching in IIS

In IIS Manager, Web site properties dialog box has “HTTP Headers” tab where you can define Expires header for all requests that IIS handles. There you can define whether to expire content immediately or expire after certain number of days or on a specific date. The second option (Expire after) uses sliding expiration, not absolute expiration. This is very useful because it works per request. Whenever someone requests a static file, IIS will calculate the expiration date based on the number of days/months from the Expire after.

For dynamic pages that are served by ASP.NET, a handler can modify the expires header and override IIS default setting.