Cache Busting with W3TC

Hello @abitofmind

Thank you for reaching out. The option “Prevent caching of objects after settings change” in Performance>Browser Cache, can be enabled for individual files, and it can be enabled for all CSS and JS files under the CSS&JS section in the Browser Cache. As it was explained in the topic you shared, and since the suggested expiration for the static files is 1 year, the “cache-busting” can be achieved with the Prevent caching of objects after settings change which adds the query string to the file, and once updated, the browser will naturally fetch a new version since it’s not the same file
For example, if the option is enabled on the plugin that has a file https://website.com/wp-content/plugins/some-plugin/css/some-css-file.css the query string will be added:

https://website.com/wp-content/plugins/some-plugin/css/some-css-file.css?x1234

If the content of the CSS file is changed, and the option “Prevent caching of objects after settings change” is enabled for CSS&JS files, all you have to do is to Update media query string which will then update the string and force the plugin to fetch the new version:

https://website.com/wp-content/plugins/some-plugin/css/some-css-file.css?x4231

After updating the query string, you also need to purge the cache.

I hope this helps!

I myself had looked at W3TC’s Browser Cache factory settings for CSS/JS files and came to the conclusion that a 1 year TTL and a max-age policy can be considered “Cache Busting ready out of the box” when serving WordPress Core JS/CSS files via W3TC, because they are already minified and uniformly all use nice ?ver=1.2.3 tags.

I just wanted a confirmation of this. From you as an expert, as I yet only know web acceleration in theory, only these weeks gain practical knowhow too.

And it was a SEO-recommendation for you and your docs to explicitly feature “Cache Busting” somewhere as it is on many “Web Acceleration” checklists / best practises.

You answered in more detail regarding JS/CSS files minified via W3TC. Thanks for this too. But my question was not related to this in particular. I had only mentioned it as the closest support topic I yet found.

So again, would you as the expert say W3TC is “Cache Busting” ready out of the box?

Hello @abitofmind

Thank you again for your feedback.

The ?1 year TTL and a max-age policy can not be considered “Cache Busting ready out of the box” because the file will stay cached for a year, and if the file name is not changed, the browser will not fetch for the updated file even if the content of the file is changed.

So the “Cache busting” option is actually “Prevent caching of objects after settings change” option, which adds a questy string to all files selected for, images, JS files, CSS files, minified files, etc.

I hope this clarifies this!

If someone reads this later, let’s summarize again:

• 1 year TTL + Max-Age Policy alone is NOT Cache Busting safe. Thanks for the added precision, Marko.
• But given (as I wrote) that nowadays all WordPress Core and Plugins JS/CSS resources uniformly use version tags, it can be considered Cache Busting safe.
• If you want to be 100% Cache Busting safe — also for a few plugins or themes which may not follow best practises for their assets — use W3TC’s option “Prevent caching of objects after settings change”.

Hello @abitofmind

Yes that is correct!

Thanks!