---
title: "Blog"
description: "Read about the background of our monitoring solution, new features and case studies"
canonical: "https://www.rumvision.com/blog/keep-an-eye-out-on-how-ios14-and-google-ads-affects-performance/"
---

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

# Keep an eye out on how IOS14+ and Google Ads affects performance

We are seeing an interesting change in the way digital marketing works right now, especially with Google Ads and how they work on IOS14+ devices. The change is based on a strange search term called "gbraid," which began showing up in our data from some clients around April.

## What is the new `gbraid` parameter?

Google Ads uses the `gbraid` query key to measure ad conversions, impression data, and other important metrics. This is critical for marketers in assessing the effectiveness of their campaigns and making data-driven adjustments. Without this function, tracking conversions in the post-cookie world could be difficult, especially on Apple devices with enhanced privacy features like IOS14+.

The addition of this query is a strategic move by Google to adapt to the privacy-focused updates of IOS14+, including Apple's App Tracking Transparency (ATT) policy, which requires apps to obtain user permission before tracking their activities.

## The impact on performance

While this appears to be a positive development, there may be a problem for online stores that use a CDN (Content Delivery Network) like Cloudflare or Varnish cache. The `gbraid` query may interfere with caching, resulting in slower load times and a decrease in Time to First Byte (TTFB),[ Largest Contentful Paint](https://www.rumvision.com/blog/largest-contentful-paint/?format=md) (LCP), and First Contentful Paint (FCP).

### Avoid performance impact with `gbraid`

It is critical to exclude the `gbraid` query ([and its variants](https://www.rumvision.com/blog/make-sure-to-check-your-caching-rules/?format=md#how-do-i-avoid)) from your caching strategies. This is especially important because Google Ads will officially integrate this query on June 1st. Don't let your visitors of IOS14+ mobiles wait longer than necessary!

## The limitations of tracking performance on Safari

Unfortunately, it's **not** as easy to [track performance on Safari](https://github.com/GoogleChrome/web-vitals#browser-support), because it isn't a Chromium based browser. Safari doesn't have Core Web Vitals because they are created by Google and not (yet) adopted by Apple. So, for example, we can't see how the `gbraid` affects things, but we do know that it will be a problem if you don't whitelist it in your caching strategy.

### Other parameters causing a high TTFB

Still, to show the possible impact a parameter can have on the TTFB, here we have an example of the `gclid`, which basically works the same way.

In the screenshot, you can see that a visitor who comes in through the?gclid has a TTFB of 1.5 seconds, while someone who comes in without a parameter has a TTFB of only 500 milliseconds. This is because the ?gclid parameter is not stored in a cache. Also, since the page is always the same, it could be cached. Also, you can see that the `gbraid` parameter has a value of 0ms. This is because Core Web Vitals measurement through Safari has some limitations.

![?gbraid in ios 14 google ads](https://www.rumvision.com/file/upload/img/screenshot/gbraid-ios-14.png)

## Conclusion and solution

Every time you find out about a new parameter or RUMvision data shows that a certain parameter makes TTFB and FCP worse, you should add it to your whitelist in your caching strategy. So, you can nost likely add the `gbraid` and `wbraid` parameters to your caching strategy so that [ad traffic has a good user experience and you don't have to pay twice.](https://www.rumvision.com/blog/google-ads-impacting-core-web-vitals/?format=md)