Max-age cache-control setting for SharePoint content

Browser-cache is often utilized to improve the performance and in particular latency of webapplications. Default, the browser will still go back to the remote web server on each request for cached resources to ask whether it can be reused from cache (HTTP 304), or has changed on the server since retrieved. For resources that rarely or never change (e.g. a specific version of jQuery library), it is beneficial to avoid the browser even send out the ‘has it changed’ requests. The http protocol supports this via ‘max-age’ cache-control header.

SharePoint supports the ‘max-age’ header setting. Application pages retrieved from the file system (12/14/15 hive) follow the IIS Response Headers setting. However, the IIS setting is not applied to content that is retrieved from SharePoint lists and libraries. If you also want to have the ‘max-age’ setting in the HTTP response for these items, you need to enable the SharePoint blobcache and specify ‘max-age’ value in the web.config: <BlobCache location="C:\blobCache" path="\.(gif|jpg|png|css|js)$" maxSize="10" max-age="86400" enabled="true"/>

Something to be aware of is that SharePoint only applies the blobcache for published items. The version of a file stored in a SharePoint library (e.g. Style Library) that has not been published, will not be cached in the blobcache. The valid reasoning here is that caching is contra-productive, as non-published SharePoint content typically is accessible to only a few persons instead of a large(r) audience. A consequence of this is that the ‘max-age’ cache-control setting will not be set in the http response for the retrieved item if the logged-on user has SharePoint permission to see the non-published version:

Publish the version, and the 'max-age' cache-control setting is included in the http response.