Browser cache control headers (client side caching)

Images.weserv.nl disables 2 (default) settings regarding to cache-control. These are the ETag header, and the Last-Modified header.

We do set the Cache-Control header. Allow me to explain this decision, using Apache-config. (Images.weserv.nl uses NGINX on all servers, but Apache is more common for most people, and we did use Apache in 2011)

Consider the following Apache settings, these are identical to the NGINX-settings we use:

Header unset ETag
FileETag None
Header set Cache-Control "max-age=31536000"

The first two rules disable ETags completely, so the browser is somewhat forced to listen to the Cache-Control header. The last rule tells the browser to cache the file 31536000 seconds, or 1 year.

Optional, we use multiple servers to serve static content, and we are not sure about the last-modified times those servers report, because each has his own version of the cache, so we also use:

Header unset Last-Modified

It tells Apache to not serve any Last-Modified headers, so browsers can only listen to the Cache-Control max-age header.

This settings are used by us on lots of high-traffic websites, and disabling of ETags and Last-Modified headers sure helped to drive traffic down to one fifth of what it used to be. Especially Internet Explorer is very sensitive to those settings.

The Yahoo Developer Network recommends turning off ETags because of this misbehavior: Best practices for speeding up your web site - Disable ETags

Disabling Last-Modified will stop browsers from asking 304 Content Not Modified requests. In my experience this is positive, because the webserver has less requests to process, and browsers rely more on the Cache-Control settings you serve. But it may or may not suit you. Some browsers will try to validate assets every few minutes if you serve them a "Last-Modified" header, and that’s why I would advice to disable the use of it completely.

If you want more information about the headers we serve, consider using redbot.org this will explain every header we serve, and why this is used. We also serve Cache-Control: public, this allows browsers to cache things even when accessing images.weserv.nl over https://

Let us know if you need more info. We are open for comments about the caching policies we use. We do run complete tests on server load, bandwidth, and CPU-cycles, for each header we place. Enabling 304 will generate 5 times more requests from browsers in our case, this could be different for your site, but I expect it to be the same.