w3 Total Cache Browser Caching Explained

The idea is to store the files locally on the visitor’s browser. Once the visitors has downloaded the CSS and JavaScript files, when visiting other pages  they only download new  HTML and images. Subsequent pages should load quickly.   However, I find while testing minification settings, it’s easier to turn off browser caching. Otherwise my browser confusingly uses cached content.

Enable W3 Total Cache’s browser caching  in the General Settings page – Fig1.  

Fig2: Browser Cache Settings

The settings on the Browser Cache page help the visitor’s browser work out if it can use its local copy of a file.

When using the first two options, the visitor’s browser first describes its local copy of a file. It then asks your web-server answer whether or not it can use this copy. The web-server either insists the browser downloads a new copy (200 response), or allows the browser to use its stored copy (304 response).  You can choose which option, you don’t need both:

  • Last-Modified Header: Gives the date the file was last modified.
  • Entity Tag: This is like a unique version number for the file.  It takes precedence over the last modified header.

There are some issues: Entity tags don’t work so well on load-balanced servers with multiple machines. Identical files on different machines can have different entity tags. They can also be used to track unique users.

However, why does the visitor’s browser even need to ask the web server if it’s local copy is OK?  If the file is “fresh”, i.e,  hasn’t reached its expiry date, then the browser uses it’s local copy, without asking the server’s permission.  There are two options, and you don’t need both:

  • Expires Header: The only valid value is an HTTP date in Greenwich Mean Time. It’s good for caching static images, as you can set a long expiry time.  It’s useful if you regularly update your blog, i.e., every  6am. So 5.59am would be your blog pages’  expiry time. However, this option isn’t available, I think, in W3 Total Cache.
  • Cache-Control Headers appeared in HTTP1.1, and  these add more options, which are described below.

If there is both an expires and a cache-control header, then the cache-control header’s instructions takes priority.   The cache control options are based on the following. I usually use the default.

  • max-age=[seconds] – Unlike expires, this specifies for how many seconds the file remains fresh, rather than an expiry time like 6am.
  • public: authenticated responses are cacheable. If HTTP authentication required, responses are private.
  • private: One user can store the response, share caches,but a proxy may not.
  • no-cache: this forces the cache to submit the request to the original server for validation before it can use a cached copy.
  • no-store: the cache cannot keep a copy under any conditions.
  • must-revalidate: this makes the cache obey the freshness commands. It stops the cache serving an expired version of the file, which under special conditions it can.
  • proxy-revalidate: this option acts like “must-revalidate”, but the command only applies to proxy caches.

Google says, if they can be trusted,  specify either Expires or Cache Control – max age, plus either Last Modified or ETag. You need both to get 100% on Pingdom.  For simple websites, a cache control header and an entity tag is good. The cache control max age depends on how often you change the content, styling and images. The expires period ranges from a few hours to 1 month. 

  • 1 day:  86,400 seconds;
  • 1 week: 604,800 seconds;
  • 1 month: 2, 678,400 seconds;
  • 1 year : 31,536,000 seconds – which is the longest period allowed by the specification.

The notes say that the Time To Live (TTL) of page cache files is set via the “Expires Header Lifetime in the HTML section of the Browser Cache Settings.  Presumably this means for how long the Page Cache files sit on your web-host’s disk.   My guess is that if you want to save hard disk space, then the HTML cache control max-age, Page Cache: Cache Preload update interval, and Page Cache: Garbage Collection Interval should all be similar amounts of time.

gzip Compression

gzip compression, in the Browser Cache options, compresses the files your server sends to the visitors’ browser. All modern browsers can handle gzip compressed files, even, I think, IE6.

However, gzip compression creates more work for the server, which might slightly slow your server’s response time. So use gzip compression with page caching, so the server doesn’t gzip the files whilst the user waits for the page.  You might need to experiment if you don’t use page caching.