If you encountered “Remove query strings from static resources” flag on your speed test run, then you might find some easy fix on this page.

– You have installed W3 Total cache Plugin in your WordPress installation
– Pingdom/GTmetrix/PageSpeed has suggested to remove query strings from statics resources
– All the query string is pretty much the same (as illustrated)
– Affecting mostly CSS & JS file

Well, if you are observing all the things above, then it is very likely that this is related to the setting of your W3 Total Cache plugin.

W3 Total Cache Setting to Remove Query Strings

This article use version 0.9.7 as a reference. Menu structure, wording, features, settings, etc. might be different on a different version.

OK, after login to your WordPress’ Administration Dashboard, let’s go to W3 Total Cache Setting to fix this “Remove Query String” problem. And on the Left-hand side menu click “Performance” ⇒ “Browser Cache“.

Be very patients as this particular page is quite long. Anyway, the whole sections on the page are:

  • General
  • CSS & JS
  • HTML & XML
  • Media & Other Files
  • Security Header

Go to the CSS & JS Section and find these settings below and tick and untick as illustrated

– Unticked: Prevent caching of objects after settings change
– Ticked: Remove query strings from static resources

A dilemma in removing the query strings

Those 2 settings, in a way, contradict each other. This is the dilemma:

  • Usually, again, usually,  when you put a query string (that’s a question mark and all the character at the end of an URL), the browser knows not to cache/remember the version of that particular item because it varies every time the query strings are altered.
  • Hence the second settings. We want the browser to cache all of these *.css and *.js to speed up website delivery because they are statics file. We even store them in our CDN to make it even speedier. Therefore, with this option, the plugin will then try to remove all kind of query strings that are being used.
  • But, when you just made an update. Say, changed the colour of the title text. You want the update to be applied straight away, right? So, in other words, you want to say: “Hey browser, remove your old cache, I got a new one here!”
  • So, w3 Total Cache combines those 2 contradictions in a clever solution:
    • It removes all the query strings that removable (some query string is indeed required)
    • But then it applies its own query string. A query string within its control which is a stationary query string to all the affected file that only changing if there is an update on the styling. In this illustration, it adds “?x45150” for the current version.
    • When you made an update, it will change all the query string to “?x45151” for example. Therefore, the browser will read/redownload the new version of the file.

The problem of a solution

Now that we have unticked that option, there is no way for W3 Total Cache to help enforcing the browser to stop caching the old one. So the workaround is:

  • Minimise change after cache, i.e: during development or when it is still being changed, do not activate any cache (including Cloudflare, etc)
  • Do manual cache purging after every update: W3TC cache purging, Cloudflare purging, browser purging.
  • Settle with your choice as quickly as you can: stop installing a new plugin or changing a style. Know the fact that if you change something, some of the visitors that already visited (and cache your old file) will not see the new change anyway. A.k.a, there is no way you can force all your visitors to clear their browser cache. I hope you understand this important concept.

Comment, suggestions, more problems?

Join our newsletter! It will email you if there is new article or news. Don’t worry, probably only a few times a month.