Google’s various page speed testing tools seem to prefer browser caching set with at least a one week expiration set. That makes great sense to me! Setting a browser cache expiration tells the visitor’s browser that is is okay to cache the content – so upon the next visit the browser will load the content from local cache rather than requesting it from the server again. That’s a big win on a couple different fronts:
1. Page Load Speed. If the page, or at least parts of the page, are loaded from cache, that is always going to display faster than a round-trip to the server. And the faster the visitor’s browsing experience is, the better the overall experience and site impression will be. Site load time has shown to have a large impact on visitor interaction with web sites.
2. Bandwidth / Data Transfers. If the data is pulled from cache rather than the server, that obviously means less data being transferred. In a case where bandwidth is tracked and allocated on a monthly data transfer plan, this means less overall usage and potentially less costs for your hosting. This would be especially important in sites that are image-heavy like perhaps storefronts that show images of varying size and quality for their products.
3. Site / Server performance. If something is loaded from cache rather than from the server, that cuts down on the number of requests that the site needs to satisfy. Sure, even the smallest of servers can commonly handle hundreds if not thousands of concurrent visitors, but hey, why make it do all that work if it doesn’t need to? Imagine if your content is all cached and you have a 50% new vs returning visitor ratio… that means that your site load would potentially be cut in half, and the server could handle twice as many visitors before needing a resource upgrade. Score!
OK. Are you sold on the idea yet? If so, here’s how to adjust this setting in IIS 7.5 (Windows Server 2008 R2 hosting)…
First open the IIS Manager on your server, expand the Sites folder and then find the site you want to manage. You can control the caching either for the entire site or for specific folders. The interface and steps are basically the same, but I’ll show screenshots of making the change just on the \images\ folder of my test site:
Once you select the folder you’ll see a bunch of standard option icons. You want to look for the HTTP Response Headers icon in the IIS section of the IIS Manager interface. I’ve highlighted it in red above.
Once you double-click on that icon you’ll see the interface change:
From this interface you’ll want to select the option in the right-hand pane to Set Common Headers. Clicking that link brings up a dialog box to set just two common header items with a few option settings:
The HTTP Keep-alive should be already selected by default – leave that alone. Let’s pay attention to the Expire Web Content option which isn’t selected by default. Once you check that box you’ll see that it defaults to expiring the content immediately… which is not helpful at all. Choose the radio button for “After” then set a date range. Google seems to prefer this caching option set to at least one week so I commonly set it to 8 days as shown in my sample image.
Click OK to save the settings and you’re all done! You can test your site using browser (IE or Chrome) developer tools to confirm the headers, or use an external testing site to confirm the caching.
I hope you find this helpful – Happy Hosting!
Brad on Google+
This is a good article and great information. If you need caching for a more complex site or you are looking for an automated rules-based caching solution check out CacheRight cache control management software which we have been making for years. If you have any questions about CacheRight let us know.
While this might look to some like comment spam, and maybe it is (:>), I’m approving it and will add the note that I’ve actually used the Port80 software in the past and it’s worth looking into if you have more complex caching requirements.
Thanks Brad. We try to tread carefully with these types of comments, but your post seemed very relevant.
Also, another useful resource for caching guidance are Mark Nottingham’s caching tutorials: http://www.mnot.net/cache_docs/