---
title: "Blog"
description: "Read about the background of our monitoring solution, new features and case studies"
canonical: "https://www.rumvision.com/blog/make-sure-to-check-your-caching-rules/"
---

Breadcrumbs: [Home](https://www.rumvision.com/?format=md) > Blog

# Make sure to check your caching rules

Visitors arrive at your website or webshop from various sources. One of those sources is probably google ads, facebook ads or another source that uses a query string. But beware: these campaigns and ads you have running can impact the user experience negatively.

[One of the reasons for creating RUMvision](https://www.rumvision.com/blog/9-motives-that-led-to-creating-rumvision/?format=md) is the fact that lab data tests and many other monitoring tools do not take certain things into account. In this case, it's a mistake that could easily be avoided, and if not just as easily rectified. All you need is a [real user monitoring (RUM)](https://www.rumvision.com/real-user-monitoring/?format=md) tool that gives you insights right after deployment.

## Here's what we came across

One of our users uses different channels to advertise and run campaigns. All visitors coming in through one of those links have a query string in the URL.

Here's the catch though: although contents could just be the same per URL, each URL might be requested with additional and more importantly different query strings. For example:

- webshop.html?gclid=abc
- webshop.html?fbclid=xyz
 
And this is frequently where problems start. Although the caching method is unaware, a specific advertisement or campaign won't lead to changing contents on the requested page. It is considered a unique URL.

Not having your cache set up correctly increases the TTFB metric's cost and hurts user engagement and conversion. And also lowers your[ Core Web Vitals score](https://www.rumvision.com/tools/core-web-vitals-checker/?format=md).

## How did we notice this?

As indicated earlier, many things are not taken into account in similar tests. This is why we have 30+ filters and dimensions to spot bottlenecks like this.

One of our filters is called the "TTFB by GET parameters". This shows which query strings cause a high TTFB. In the screenshot below you can see that Facebook Ad clicks have a worse experience.

![1656609593941.jpg](https://www.rumvision.com/file/upload/img/blog/1656609593941.jpg)

### Lets break it down

The average TTFB is 285ms. This is very neat. You can see that about 85% have a good experience (green). When someone enters without a query string, this is 223ms, even better. What you see next is interesting. We see a gclid and a fbclid. So both are ads that ended up on the same page. However, the difference in the TTFB is huge. The fbclid visitors have an almost 6 times worse experience (2116ms) than those coming through a gclid (366ms), and almost 10 times worse than visitors entering the page without a query string.

## How do I avoid this?

Well, very simple actually. Ignore query string parameters that won't affect the contents. Many parameters don't have or need this behavior, even though pagination, search, or filtering parameters in a query string will produce different HTML.

When you are in the process of setting up your caching strategy rule out the following:

- **UTM**  
    utm\_source  
    utm\_medium  
    utm\_campaign  
    utm\_id  
    utm\_term
- **Facebook**  
    fbclid
- **Google Analytics**  
    \_gl
- **[Google Ads](https://support.google.com/google-ads/answer/10417364)**  
    gclid  
    gad\_source  
    dclid  
    wbraid  
    gbraid  
    srsltid
- **Search Ads**  
    gclsrc
- **Microsoft**  
    msclkid
- **Pinterest**  
    epik  
    pp
- **Other**  
    channable  
    awc (awin.com)  
    dm\_i (dot digital email)
 
These are the most standard ones you will encounter, [but there are a few more.](https://maxchadwick.xyz/tracking-query-params-registry/)

## How real user monitoring comes into play

The problem itself can be easily prevented without using real user monitoring, but people make mistakes. No problem, when you can correct them quickly. But if you depend entirely on Google data, **which is 28 days delayed**, then it may have cost you a lot of money. Very simply put, you are spending money on visitors who are going to have a bad experience. This makes them a lot less likely to convert.

With real user monitoring, you have immediate insight into your data, **without having to wait for it.** Of course, there have to be visitors, but you get the point. This gives you the opportunity to see if everything still works as it should after the deployment and you can for example in this case immediately adjust your caching strategy and not "throw money away" for 28 days.