Making sure paid traffic has the best page speed possible

Summary: If your ecommerce depends, or receives a lot of ad traffic, it is a must to be sure they have the best possible experience in terms of Core Web Vitals and page speed. In this article, we explain how RUM ensured that the ad budget was spent well.

  • by Jordy Scholing
  • Published
  • Reading time ± 2 minutes
  • TTFB Paid Traffic
Making sure paid traffic has the best page speed possible

What you should know about ad traffic and performance

We've written before about the fact that ad traffic is (often) a worse experience than non-ad traffic. This is because a wait/redirect time is added when someone clicks on a "sponsored" link in Google SERP, for example.

  • Non ad visitor:
  • Ad visitor:

The "gad_source" and "gclid" will add a redirect to the request for statistics and tracking purposes. Other than that this page should be able to come out of the cache, since both pages are serving the same content in this case.

Breaking down the waiting time

From data we know that on average the waiting time is around 200 to 500ms. There is little you can do about this, unless you start working with parallel tracking.

TTFB core web vitals breakdown

In ecommerce the redirects are often the reason for higher waiting times.

Get an optimal server response time

Nice to know that there is a waiting time, but there is not much you can do about this in many cases. Good point, but there are other things that often go wrong with ad traffic. Namely, the fact that the browser cannot retrieve the URL from the cache, while the content on the page is the same for both types of traffic.

The image below shows a breakdown of one and the same URL, only the second URL has some parameters included. What is noticeable is that the server response time there is 20 times higher than the URL where there are no parameters.

TTFB breakdown server response time high

This is painful and extra expensive traffic because it comes from a paid campaign.

The impact on UX metrics

Okay, the TTFB is not a metric that is directly perceived by the user apart from the fact that they wait longer for something to happen to the page. But a higher TTFB also affects two other metrics, first contentful paint and largest contentful paint.

The image below shows how the metrics score for visitors coming in with that paramater. You can see that the FCP and LCP take about 2.5x as long.

Non-ad visitor:

  • TTFB = 296ms
  • FCP = 913ms
  • LCP = 1277ms

Ad visitor:

  • TTFB = 1628ms
  • FCP = 2346ms
  • LCP = 2799ms

FCP and LCP suffering from high TTFB

Knowing that a hundred milliseconds can already make an impact on business metrics, the math is easy for more than 1 second.

RUM saves the day

Okay, where people work mistakes are made, everyone agrees. But by deploying the right tools and real-time insights, you limit the odds and ensure that paid traffic has the best possible experience. This client, through the technical dashboards in RUMvision and the visitor footprint, was able to see deterioration within the TTFB. By analyzing, it became clear that it was due to the parameters we talked about.

real-time user insights

Take action right away

Because the insights come in directly to a RUM solution, you can also act immediately when data comes in. For example, this client was able to make an improvement within 12 hours, which in turn gave these visitors a good experience.

Without RUM, this customer was unable (or a lot harder) to figure out where the high TTFB within CrUX data (here it also takes 28 days before you have fresh data) for example came from. By applying dimensions, templates and the right filters, you are always ahead of the curve.

Share blog post