Cache Busting in W3TC: How to force your visitors to see your theme’s updated JS and CSS files


Sometimes modifications to existing .js and .css files are not reflected for users visiting your website. This occurs because those files have been cached in the user’s browser from a previous visit and the cached version is served instead of the most recent version. The expiration of this cache is called time to live, or TTL and it is associated with this local cache in your browser, which is why it will show the old version until this length of time has passed. To see the correct version of the files, the user has to either clear the browser’s local cache & reload the page or do a hard refresh of the page by pressing Ctrl+F5 to ensure their browser is using the latest file versions.

When a user tries to access the URL, and the browser starts fetching the page data, it sees that it already has the page’s stylesheet E.G. style.css, and  says “Wait!, I already have this file cached, so I don’t need to fetch it again and can just present that to the visitor”. And the Browser has a point!

What is Cache Busting?

Asking each and every user to clear their browser cookies or do a hard refresh is not reasonable and leads to frustrating user experience. To remedy this, we can use a technique known as Cache Busting. Cache Busting works by appending a unique query string to the path of the .js or .css file that tells the browser there is a new file to add to the cache memory.  When the browser loads a page using these query strings it downloads any unrecognized files and displays them for the visitor.

How can I fix this?

You can use any unique query string you want to bust the browser cache, but the easiest way to guarantee a unique string is to use version numbers.

For example:

Let’s say you make some changes within your theme’s main JS file:


After updating the file simply add a version number query string ?v=1.0


This way when the browser will see the updated JS as a new .js file which is not cached. So it will generally force the browser to update the JavaScript/stylesheet. So, each time you update your JS/CSS on the server, you can incrementally update your version number so it busts the previously saved browser cache.

You can accomplish this when you enqueue your script by adding an argument for the version, for example:


WordPress 5.3 Beta 3 Released


WordPress 5.3, scheduled to be released on November 12, and contains numerous improvements for site performance and user experience.

Server-Side Block API

PHP enthusiasts (and JavaScript haters) will be glad to know that there is now a server-side API for creating blocks in the WordPress Block Editor (Gutenberg). When asked about the performance impact of registering new blocks this way, Core Contributor Jorge Costa suspects that the impact should be negligible unless compared to a JavaScript file that is registering a large number of new blocks, which could be cached by the browser:

For most cases, the performance should be equivalent. The PHP code dynamically generates an inline script with the equivalent JavaScript code to register a block style and generates an inline style with the classes. If many block styles are being registered having a single JavaScript file that registers all the styles and a single stylesheet that includes the styles may be more performant than registering the styles with PHP. In that case, the JavaScript and CSS files will probably be cached by the browsers while for inline scripts/styles it is not possible to take advantage of caching.

Better Large Image Uploads

An update to the WordPress REST API will solve a major pain-point for many users— better handling of large image uploads. Previously, if the server returned a 500 error at any point during the upload process, the upload would fail. Now, the request will automatically reconnect and attempt the upload again, as well as generate the attachment sizes at the very end of the request.

In another improvement to the REST API, you can now use Objects and Arrays to create Post Meta-based Gutenberg blocks.

Twenty Twenty Theme

The Twenty Twenty theme has excellent performance according to our tests. The developers have included the Inter typeface, which includes all of its weights and variations in just two files—  which are served directly from the website rather than using cross-domain requests.

Modernizing the Date/Time API

The WordPress Date/Time component has historically relied on the sum of the Unix timestamp and a time zone offset, which caused a great deal of confusion since the inline documentation referred to it as simply a Unix timestamp. Developers would need to account for this difference when comparing two timestamps against each other.

The new API allows developers to fetch a timestamp as a true Unix time or a DateTimeImmutable object, with methods to set timezone offsets in a reliable manner.