If you ever do a page speed check on your site, you may have seen the notice to “Remove query strings from static resources.”

What Are They And Why Do I Care?

At their most basic, a query string is any URL that has a ? in it. For example, if you go to a url of https://example.com/?lang=en then that last bit is the query string. It’s job is to tell the browser to pass on specific information to the website. It’s essentially a variable that will be read by the website or the browser.

A static resource is a file used by a website that doesn’t change much (if at all). These are usually images but also CSS (style sheets) and javascript files. These resources can be stored on web servers, proxy/CDN servers (like Cloudflare or MaxCDN), or even a web browser, which makes your sites run faster.

However. The explanation is that browsers don’t cache anything with a query string. Which means, yes, if your static resources have one, they won’t get cached.

Or will they? (It’s complicated.)

Why Do My Resources Have Query Strings?

If query strings break caching, why would anyone have them? Because we don’t always put version numbers in our paths for common files. For example, in WordPress if you call jQuery (a common javascript library), you’re calling a path like https://example.com/wp-includes/js/jquery/jquery.js and that has no version number. But WordPress has certainly updated that a number of times.

In order to make sure that jQuery gets properly cached when you upgrade, WordPress adds a query variable like this: https://example.com/wp-includes/js/jquery/jquery.js?ver=1.12.4

This is important because otherwise when you upgraded WordPress, you’d see a page formatted weirdly and misbehaving, all because the wrong (cached) jQuery was loaded.

Should I Remove The Query Vars?

Maybe.

Yes, allowing your resources to be cached will make your site faster, and it will get you a higher score in those page speed checks. At the same time the speed benefit is pretty low compared to the dangers of those files not being properly updated. Features on your site will, literally, cease to function.

So you’ll need to decide for yourself which is more important.

Reader Interactions

Comments

  1. Huh? Browsers do cache resources with query strings, if you set an Expires header. As I’m sure you already know, and practice.
    e.g. Apache:

    ExpiresActive On
    ExpiresByType text/css "access plus 1 month"
    ExpiresByType text/javascript "access plus 1 month"
    

    or nginx:

    location ~ .(?:css|js)$ {
        expires 1M;
        add_header Cache-Control public;
    }

    Once upon a time, some old caching proxies didn’t honour that for resources with query strings, but they’ll have long since died out.

    • CAN cache, but funny enough, they don’t actually seem to all the time. And they certainly don’t pass ANY validator I could find.

    • @Ipstenu (Mika Epstein): They seem to all the time if you set an Expires header 🙂

      Validators that aren’t accepting resources with query strings and Expires headers are broken. Which is most (all?) of them. Last I looked, the big ones said something about old caching proxy servers, which is a non-issue in 2017.

      The real problem here is that people are being given checklists of how to make their websites faster, and one item actively damages their websites: removing query strings from static resources, which you’ve nicely covered in your article. I have a canned response in HelpScout for related support problems because it’s so common.

    • If they’re set but you can’t validate them, are they set at all? Which is a metaphysical question really…

%d bloggers like this: