This is a simple PERFORMANCE TIP when using cache plugins:
- The idea is to ignore query strings.
I’ll explaining what they are, why you should ignore them, and how to do it!
Credit to this guide should go to Gijo Varghese of WP Speed Matters, who already wrote the guide “Improving HTML Cache Hit Ratio by Ignoring Query Strings“. He was the one that reminded me of it, linked me to his great guide and now inspiring mine. I linked to him flat out so you don’t have to waste any more time on my site…just click the link above.
Or ok fine, read my very own explanation below.
What are query strings?
Query strings are usually little strings of text or numbers that come after URL’s. Some examples below (shortened for brevity):
- https://google.com/search?=wordpress+tips
- https://yoursite.com/wp-content/theme/style.css?vers=5.3.2
- https://yoursite.com/?fbclid=IwAR1R-T-n
- https://www.amazon.com/dp/B07D9GMYG8/ref=?tag=yourname
- https://shoestore.com/shoes/?filter_size=5&query_type_size=or
Basically, anytime you see a question mark “?” followed by letters or numbers…THAT’S a query string!
And what are query strings used for?
They’re used to pass information to the web-server for some specific purpose.
- Example #1 above was to link directly to the Google search results for a set of keywords.
- Example #2 was to pull out the latest version of a CSS stylesheet, using the query string to bypass cache. Without it, browsers might see a precached (stale) version.
- Example #3 was to set a Facebook tracking cookie, for conversion tracking purposes.
- Example #4 was to give credit to the referring Amazon affiliate.
- Example #5 was to link directly to the filtered product choices.
As you can see, there are many ways to use query strings!
Why should we exclude query strings in cache plugins?
The thing is cache plugins cache all URLs individually. Suppose you had 3 pages….
- https://domain.com/page1/
- https://domain.com/page2/
- https://domain.com/page3/
Your cache plugin would save one copy of each page and serve that copy to visiting users (instead of regenerating the page from scratch). And it only makes sense as each page needs its own different cached version since it’s entirely different page (different content, maybe even different design).
Now the thing is…cache plugins also see query strings as unique pages! So for example…
- https://domain.com/page1/
- https://domain.com/page1/?abc
- https://domain.com/page1/?fbclid
The cache plugin sees those 3 pages above as all being unique from each other. And that’s a problem because some query strings should be cached separately, but others shouldn’t.
- Any query string that affects what the page shows (like search results) should be cached individually (normal behavior) since each query string would give different page content.
- Any query string that DOESN’T affect the page content/design (like tracking cookies) should definitely be cached all the same as the original page.
So basically…we shouldn’t cache cookie-related query strings. The most common ones I recommend are listed below:
- fbclid
- ref
- utm*
The “fbclid” one is the one that Facebook puts on all links being clicked from Facebook. The “utm” one is used by Google for conversion tracking. And the “ref one is commonly used by many plugins/services to track referrers. You should definitely exclude these queries for 2 reasons:
- REASON #1 – so your cache plugin can just load the same cached page as the original URL (without query string). You get faster load!
- REASON #2 – so your cache plugin doesn’t waste a ton of space regenerating a new cached page for every new query string.
Yeah, it’s crazy. Think of all the times and all the users who clicked on your links from Facebook only to get an UNCACHED version of your site! It’s funny right…after all that work you did trying to speed things up.
If your site uses other query strings, like for your affiliate plugin, and such…you can add them, too. Don’t worry, you can safely exclude these query strings since the page is the same regardless. And whatever tracking functions they serve will still work since the server still registered a HIT for those query string urls.
How to exclude query strings in your cache plugin
I only show instructions for the top 3 cache plugins: Swift, WP Rocket, and LiteSpeed Cache. If you’re using another cache plugin, the principles are still the same. Luckily though…many cache plugins are probably already excluding the most common (unnecessary) query strings. You can also see the WP Speed Matters guide which shows helpful images.
Swift Performance:
- Go to Settings (choose “Advanced View”) > Caching > Tweaks > check “Ignore Query String”
- Swift automatically ignores “fbclid” and “gclid” by default.
- And if you check the ignore query string option, it ignores for all query strings…which unfortunately breaks functions like “search” which rely on query strings.
- Maybe we can write to them to ask for a way of selectively ignoring only chosen keywords.
WP Rocket:
- WP Rocket automatically ignores: all utm tags (utm*), fb_action_ids, fb_action_types, fb_source, fbclid, _ga, gclid, age-verified, ao_noptimize, usqp, cn-reloaded.
- To selectively ignore other query strings, download their helper plugin. Also see the WP Rocket guide on query strings.
LiteSpeed Cache:
- LiteSpeed caches all query strings (individually) by default.
- To selectively ignore query strings, go to Settings > Cache > Drop Query Strings…and fill them in yourself.
- Put each one on a separate line. (fbclid, ref, utm*)
- See helpful LiteSpeed guide on removing query strings.
Regev
Do you pick Standard on Cloudflare (instead of Ignore Query Strings) since the load is on *their* servers anyway?
Johnny
Yes, I leave it standard. But the thing is Cloudflare only addresses query strings on static assets (domain.com/theme/styles.css?vers3.1)…whereas this guide talks about cache plugins addressing query strings in dynamic pages (domain.com/page/?ref=1234)
Park TH
Openlitespeed doesn’t support Ignore querystrings, they are sneaky with this one.