Campaigns and ads are impacting your Core Web Vitals via TTFB

Campaigns and ads are impacting your Core Web Vitals via TTFB

You might not be aware yet, but chances are that the e-mail or social media campaigns and ads you're running, are impacting user experience.

Let's take one step back: when a visitor visits a page on your website or webshop, a request is sent to the origin server. This is a physical server with your dynamic files (Node.js, PHP, et cetera). These files are then responsible for generating HTML, which basically is server side rendering.. on the fly. TTFB is a metric telling us when the first bytes of HTML was received by the browser.

Server side caching to reduce TTFB

But you, or one of your colleagues were smart and implemented some sort of server side caching. This reduces the amount of work needed to be done on the server to come back with HTML whenever it is requested. The server, or your very own platform knows which page to return based on its unique URL.

As a result, TTFB will improve.While you could still hack your LCP metric without improving TTFB, metrics such as FCP and LCP will always benefit even more when improving TTFB, resulting in an additional boost of your Core Web Vitals.

Query strings impacting TTFB

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:

  • home.html?gclid=abc
  • home.html?utm_campaign=xyz

And this often is where issues arise. A specific advertisement or campaign won't result in different contents within the requested page, but the caching mechanism doesn't know. It just sees this as a new unique URL, hence putting the server and your dynamic files at work, creating HTML on the fly once again.

This is adding costly time to the TTFB metric, impacting user engagement and conversion via those other metrics (FCP, LCP).

Ignore (common) query string para­meters

Quick win: ignore query string para­meters which won't be impacting contents. While pagination, search or filtering para­meters in a query string will result in different HTML, there are a bunch of para­meters which doesn't have nor need this behaviour.

So, as part of your caching strategy, be sure to ignore the following para­meters:

  • UTM
    utm_source
    utm_medium
    utm_campaign
    utm_id
    utm_term
  • Facebook
    fbclid
  • Google Analytics
    _gl
  • Google Ads
    gclid
    dclid
    wbraid
    gbraid
  • Search Ads
    gclsrc
  • Microsoft
    msclkid
  • Pinterest
    epik
    pp
  • Other
    channable
    awc (awin.com)
    dm_i (dot digital email)

An even longer list can be found here.

When using Cloudflare

When using Cloudflare, Cloudflare will make it easy for you to determine if you're having caching issues. Check the response headers of your webpage and look for the cf-cache-status header. It should read HIT. If not, Cloudflare did not return a cached page for whatever reason. One of those reasons could be query string para­meters that you didn't exclude yet. Read how to properly setting up Cloudflare for faster TTFB.

So, be sure to add the above para­meters to your ignore list as it's a no-brainer which will obviously improve not just metrics, but also:

  • (early) user engagement;
  • bounce and conversion;
  • SEO via Core Web Vitals;
  • And maybe even ad spent/CPC, a win/win!

Know of more common para­meters? Let me know and I'll add them.