style.css is changed to
style.css?ver=4.9.2. The version automatically updates with each WordPress release and helps with cache busting. WordPress developers can also easily change versions to something custom, like today’s date, when adding assets with
wp_enqueue_script. That makes sure customers see their website with the latest development changes applied.
Website SEO and improvement tools always recommend that these query strings be removed.
If you run a website performance grade scan you’ll most likely see recommendation to remove query strings from static resources. Using Pingdom’s tools on https://anchor.host shows website performance grade goes from a D rank (60) to a C rank (70). The only difference is the query strings.
You might be thinking, if it’s that big of deal why don’t more people ditch the query strings? Well… convenience. Without query strings web developers are left with finding an alternative solution for cache busting. The actual removal of query strings is quite easy to do. For free you can use a plugin like Remove Query Strings From Static Resources.
Alternative cache busting exists but they require extra configurations and planning.
Chris Coyier did a fantastic write up on the topic. Even though his article is a few years old the alternative recommendations are still valid. The most obvious solution is to rename the files themselves rather then adding a query string. This makes the performance graders happy as your files can properly be cached on all systems. So something like
style.4.9.2.css rather then
style.css?ver=4.9.2. The problem is that any automatic solution requires changes to web server itself (.htaccess or nginx config). This also isn’t something a standalone plugin can solve as shown in the Filename-based asset cache busting plugin.
WordPress won’t fix due to lack of a solution which works for everyone.
The official ticket #29201 is 4 years old and is marked as
wontfix. This isn’t due to lack of interest however there simply isn’t a solution proposed that doesn’t require unwanted consequences.
Disable and deal with caching as needed
I’m hesitant to recommend any automatic solution as they include unintended issues. Portability becomes a factor. Outside customization to the web server won’t be included in website backups and most certainly won’t be carried over if the website is moved to a new server.
My solution is a simple but not automatic
I do disable query strings on resource files using a WordPress plugin called perfmatters, although the freebie mentioned above also works. Then as part of my development workflow I manually rename asset files and change their enqueued name as needed. With that done the performance graders are happy and no extra server configurations is required.