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, 201C/default.aspx201D is cached on the browser. If you request 201C/default.aspx?123201D 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 201C/default.aspx?456201D 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 201C/welcome.gif201D, make sure from another page you request the same file using the same URL. One common mistake is to sometimes omit the 201Cwww201D 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, you2019re 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. You2019ll 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 201C/static201D 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 201C/static/images/somefile.gif201D. Later on, we will learn it2019s 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 201Cstatic201D 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, don2019t just update the file because it2019s already cached in user2019s 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 201C/static/images/indicator.gif?v=1201D. When you change the indicator.gif, you can overwrite the same file and then update all references to the file to 201C/static/images/indicator.gif?v=2201D. 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
It2019s 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 don2019t 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 don2019t 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 there2019s no Content-Length header, browser doesn2019t know how many bytes it2019s 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 201CHTTP Headers201D 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.