Last updated on

Browser caching is extremely important for improving your WordPress performance and speed, and it is recommended that you enable it in nearly all situations. The good news is that it is very easy to enable for WordPress with W3 Total Cache. Browsers are already parsing HTTP headers for your website, so we can add some information to these headers that declare how long the assets should be held on to locally, or if the browser should download a newer copy.

When users visit your site, their browser will examine the HTTP headers being passed to determine if it should store a local copy of the assets. Not only will your site load faster for users since they are loading local copies of your stylesheets, javascript, images, fonts, and etc, but these assets will not have to be served from your hosting plan when a user navigates through your site.

W3 Total Cache Logo

Speed Up Your WordPress Website.

A Difference of Just 100ms in Page Load Speeds Can Cause a Visitor to Prefer Your Competitor’s Website.

W3TC General Settings Overview

Here we will review the Browser Cache > General Settings section in W3 Total Cache for WordPress and examine what each of the available settings do. We will focus on the global settings, but these are applicable to other sections as well.

W3 Total Cache Browser Cache Settings

Set Last-Modified header (Recommended)

The Last-Modified response HTTP header contains the date and time at which the origin server believes the resource was last modified. It is used as a validator to determine if a resource received or stored is the same. It is less accurate than an ETag header, so consider it to be a fallback mechanism.

Set expires header

The Expires header contains the date/time after which the response is considered stale. Invalid dates, like the value 0, represent a date in the past and mean that the resource is already expired.

It’s not suggested to use Expires header for HTML assets. Use it only when there is too much HTML traffic present on your website, as this may result in some users not seeing the latest published content.

Set cache control header (Recommended)

The Cache-Control general-header field is used to specify directives for caching mechanisms in both requests and responses. Enabling this setting will encourage browsers to cache files/assets.

Set entity tag (ETag) (Recommended)

The ETag HTTP response header is an identifier for a specific version of a resource. It allows caches to be more efficient, and saves bandwidth, as a web server does not need to send a full response if the content has not changed. If your WordPress host doesn’t offer unlimited bandwidth, using the ETag can help prevent any bandwidth overage charges too. Otherwise if the content has changed, etags are useful to help prevent simultaneous updates of a resource from overwriting each other.

It is suggested to enable ETags while Set expires header is active, along with Prevent caching of objects after settings change as these combined will force browsers to reload assets when they are updated. This prevents users from seeing old content after changes are made.

Enable HTTP (gzip) compression (Recommended)

Enabling this will serve your assets after they are compressed by gzip, which reduces the amount of data that a user needs to download to be able to view your site. This is generally recommended as it is extremely useful for users on low-bandwidth devices and is supported by almost all browsers and devices.

Enable HTTP (brotli) compression

Brotli is a newer compression algorithm that is supported in most modern browsers and is better at reducing the compressed size of most assets compared to gzip. While it is considered to be better than gzip, not all devices and browsers are supported. What is Brotli Compression, and why do I need it?

Prevent caching of objects after settings change (Recommended)

When settings are changed, an additional query string is generated and appended to objects to force the new policy to be applied.

Remove query strings from static resources

If a URL has a query string, it typically will not be cached some proxy caching servers unless they are explicitly configured to do so. Leave this disabled unless you require it for your specific needs.

Congratulations! You now know how to configure browser caching for WordPress in W3 Total Cache. Next, you may want to configure Object Caching for WordPress with W3TC.

W3 Total Cache

You haven't seen fast until you've tried PRO

   Full Site CDN + Additional Caching Options
   Advanced Caching Statistics, Purge Logs and More

Everything you need to scale your WordPress Website and improve your PageSpeed.

1 thought on “Configuring WordPress Browser Caching using W3 Total Cache

  1. abitofmind says:

    “Remove Query Strings From Static Resources”

    I had wished for a bit deeper explanation.

    E.g. consider example.com/green-trousers/

    If you use campaign links like /green-trousers/?campaign=newsletter what does this your setting do?

    1) Assumed you have no reverse proxy (like Varnish) in front of your origin server:

    a) The origin server gets /green-trousers/?campaign=newsletter
    b) and with a mod_rewrite rule in .htaccess redirects to /green-trousers/ which then gets served from cache?

    Is it working like this?

    Which records ends in your log? Only 1a or 1b or both? I assume both and that campaign measuring software can determine from the log that 1a and 1b belong together.

    If you disable that will you end up with a cache-directory for each or the argument-variants for that static resource?

    /green-trousers?campaign=newsletter/_index_slash_ssl.html
    /green-trousers?campaign=newsletter/_index_slash_ssl.html_gzip
    /green-trousers?campaign=twitter/_index_slash_ssl.html
    /green-trousers?campaign=twitter/_index_slash_ssl.html_gzip
    /green-trousers?campaign=partnerX/_index_slash_ssl.html
    /green-trousers?campaign=partnerX/_index_slash_ssl.html_gzip

Leave a Reply

Your email address will not be published. Required fields are marked *