Using tools such as Pingdom and Google PageSpeed Insights I commonly see a message simliar to the following from WordPress powered sites:

Remove query strings from static resources

This week I have been on a performance optimization kick for a client and have been using this site as a testbed for optimizations. By default WordPress appends a version number to all Javascript and CSS asset files going through the enqueue system but it is pretty easy to rip the query string out.

Remove the query string from assets

Removing the query string can be done rather easily. I tossed the following code snippet into an mu-plugin and it “just worked” to remove the ver query string from Javascript and CSS files. In most cases this is all that is needed to prevent query strings on these assets:

function blob_remove_script_version( $src ) {
return remove_query_arg( 'ver', $src );
}
add_filter( 'script_loader_src', 'blob_remove_script_version', 15, 1 );
add_filter( 'style_loader_src', 'blob_remove_script_version', 15, 1 ); 

Did it help?

Definitely maybe…

The site was already loading very quickly. Performance may have increased in the hundreds of milliseconds saved, but then again it could have just been some requests running faster than others. As we all know timing is not an exact science on the web. Not everything is happy in candy land though…

Caveats to removing the query string

Lets assume those few hundreds of milliseconds did give a performance gain; is it worth it? After chatting with the WordPress caching god Zack Tollman the answer seems to be a resounding “no”. Zack led me through a series of scenarios with the primary being updates to said assets.

Take this url javascript asset as an example: https://ben.lobaugh.net/site-functions.js. WordPress would spit out https://ben.lobaugh.net/site-functions.js?ver=4.0.1. Later on an update the url may become https://ben.lobaugh.net/site-functions.js?ver=4.2. Why would you care? Cache busting. That file contains essential functions for site operation. Without the query string your site visitors may be using a cached version of the js file. This could cause your site to be broken until the file expires from their local cache or they manually refresh. As the site owner/developer you do not have control over when that happens, however if you use that query parameter and change the version number the client will see it as a new asset and load in the new file and recache it. The first load may be a bit slower but subsequent loads will again be speedy.

But doesn’t the query string prevent caching? The short answer is no, the longer answer is it depend on the caching mechanism. Query strings are common place on the web today and in most cases these days caching mechanisms respect query strings and will cache the file.

Is there a better way to do this?

Possibly. Google actually recommends embedding the file version in the url path instead of using a query parameter. This does make it look like a second file and could make linking to the file a touch more difficult. Busting the cache with a new version in the url parameter is a form of a new url path though anyways. Does it make much difference beyond the performance testing tools in the everyday browsing experience? I will leave that to you to decide but my suspicion is probably not.

My takeaway

My takeaway from all this is that while there could be a slight performance gain from removing the query strings it is very likely not worth the headache that will be caused by updates to the site. In the WordPress world site owners are encouraged to update WordPress core and plugins/themes as they are available. Updates may be available on a daily basis. Having WordPress automagically take care of busting the cache for these assets and ensuring the visitor is always able to access the site is far more valuable than saving a few hundred milliseconds of time.

hello dog