I could have called this post one of a million things, but attention grabbing is where it’s at.. right?
Of all of my time working with customers sites, solving their site issues the biggest take away is the insta panic should something.. no, anything not be as expected instantly. All rationale goes out the window and there is only one conclusion.. it’s broken!
So this post is going to cover something I always use as my first go to tool, it’s nothing fancy, it’s not something you need to download but it can help pinpoint if really your site is broken or something else is involved… usually caching.
Meet the query string!
What’s interesting is that for all of the developers I speak to, so little have ever heard of the query string, and importantly how it can help their workflow ten fold when checking for odd behaviour.
A query string is something that attaches on to your URL in the browser and can look something like this: https://mydomain.com?somethinghere Notice the question mark followed by something (anything).
I’ve seen this before, but why? So many things use query strings as it allows for traffic to function as normal when visiting your site but it can be used to track certain entry points for example you may have a partner link of which you could supply them a URL such as https://mydomain.com?billsburgers now when it comes to track where your traffic is coming from you now can see all of those referrals (in it’s most basic sense).
While all of that is fun and useful for other things in this case we want to use the query string for testing/development so on we go.
The next part is kinda super important and refers to Caching, and how that works so this is a super brief Caching 101 for context.
If your site is setup with caching enabled, be that via the hosting platform or elected plugins when you make a request to https://mydomain.com for the first time the caching layer of the site will/should now create a copy of that page of which it stores so if another request is made to the same URL it can serve that super fast. Caching typically has a lifespan of say 60mins, so then any new requests to that URL will get served the caching. Fantastic for when you want your sites server resources to go further and serve more. (I did say it was brief).
Now this is where Query Strings come in, if you visited the same URL https://mydomain.com?123 now, the request is seen as being different from the cached version of the site saved, so will serve you a brand new uncached version of the site. HOWEVER, now you have visited that URL using that query string, that IS now cached, so if you visit again to the exact same URL you will be served the cached assets.
Okay so how does this help me?
Well think about this, if you have ever (shudder) updated CSS on a live site and visited and then scratch your head as the changes have not turned up to the party? That’s dear old caching at play, your browser has been served the cached copy of the page (pre-updates) and that will remain that way for the lifespan of what the cache is set to.
So to see your changes, this is where you can test using a query string. So by adding ?anythinghere123 to the end of your URL, you will be served with a uncached page load and in theory should now be seeing those changes. Amazing right?!
Awesome, so back to the title (My site is down), using a query string to test load your site ANYTIME you have issues, is an absolute must, your site may be down and not loading, but using the query string it works, simply because the caching may have stored a bad request.
I can guarantee this changes your life, of all site based issues as a loose estimate I’d say 60-70% of those we can rule out major issues using a cache busting query string.
So say my site works with the query string but not on it’s own how do we fix this?
Good question, and I’ll just share my simple rule. Flush the cache from the site outward. I’ll explain.
In many cases I work with, as we provide server level caching, we find sites also have plugin based caching and even theme based caching and not to rule out DNS level caching (CloudFlare) and then Browser level caching. (wow that’s a lot of caching).
So simply put, I work with the theory that everything starts with the site and then caches that working outward towards the requestor/visitor. So I clear any plugin/theme based caching, then server level caching (as the server caches what the site provides), then the DNS level caching (as that caches what the server outputs), then finally the browser cache, as that’s the end of the line.
While not an exact science, as each setup is different this in most cases results in faster issue resolution, better understanding of where the issues lay and helps rule out caching as an issue if the query string loaded pages also display the same issues.
To flip this situation around, I may see an alert that a sites down, I’ll check in the browser, nope all good working! But that’s not the end of the road, using a query string for a fresh uncached result may actually show the site is broken and just good old caching is helping serve customers with it’s pre-stored data. So again using a query string can help us find out what the situation is as a first point of call.
Hope that helps!
