Facebook now adds fbclid query string to URLs, busting CloudFlare's cache

forum uses markdown code so you can enclose long segments of code in start and closing 3 backticks

 ```
  yourcode
 ```
2 Likes
Thanks a bunch @eva2000 ! Same as on Github then.
1 Like

Hello guys,

Since everybody here is referring to NGINX, I believe that majority works with Apache, right? So I found this thread on stackoverflow that can help us out, didn’t test it yet but I intend to. Stackoverflow link

The user there refers to 301 redirect I would rather us 302 so the final code could be like this in our .htaccess file

RewriteCond %{QUERY_STRING} "fbclid=" [NC]
RewriteRule (.*) /$1? [R=302,L]
1 Like

Hey again,

Second try my solution above will not work because IF we pass the other parameters it will remove all the rest so there should be way to preserve the rest of the query parameters that we need like utm_source, utm_medium and etc. So I came with another solution in .htaccess.

# Handle fbclid query parameter
RewriteCond %{QUERY_STRING} ^(.*)&?fbclid=[^&]+&?(.*)$ [NC]
RewriteRule ^(.*)$ /$1?%1%2 [R=302,L]

Link that helped me this time was Stackoverflow link

3 Likes

Hey @matija.baric, it’s great that you provided a solution for people who want to do it on their Apache servers!

You could also use @boynet2 's solution at the Cloudflare level to do a redirect. It will also ensure the requests going to your Apache server never have the fbclid paramteter. And you don’t even have to modify your server’s config!

To make a redirect at the Cloudflare level simply create a Page Rule with the following:

http://www.example.com/*?fbclid=* forwarding 302 to http://www.example.com/$1
2 Likes

Would like to add some context:

The parameter showing up is mainly for this new attribution tracking feature they’re launching for businesses, but IMO it’s a pretty good front for getting around Apple’s ITP 2.

Facebook is doing this in response to Apple’s third-party cookie tracking protection that prevents FB from tracking users just by cookies/embeds, see Intelligent Tracking Prevention 2.0 | WebKit. With fbclid, Facebook no longer needs to rely on tracking cookies to track users across websites.

3 Likes

Thanks for the info @Judge! For sure it’s an excuse to getting around Apple’s ITP 2. And it also creates the problem of cache busting most servers. In my opinion, this is another bad move from Facebook who never seems to care about the needs of publishers. But Mark Zuckerberg said it himself that he doesn’t care about publishers, so nothing new there.

Since August 2 2017, Facebook has been penalizing slow websites as mentioned in this article: Showing You Stories That Link to Faster Loading Webpages | Meta

By busting the cache of publishers’ servers with their fbclid parameter, they are essentially going against their own policy of “Showing You Stories That Link to Faster Loading Webpages” since the requests made to those servers will surely be much slower without any cache busting protection system put into place. This is essentially what this thread is about. To try and find ways to protect our servers from slowing down because of Facebook’s reckless actions.

1 Like

Hey everyone, thanks to @boynet2 I think I managed somehow to bypass this issue. But it’s extremely odd, it doesn’t seem to work on mobile? It’s like page rules aren’t working on mobile? Did anyone have that kind of problem?

Thanks!

1 Like

@beeroslav, Page Rules work perfectly fine for me on mobile.

Maybe you have a setting that’s blocking them?

Just a thought.

1 Like

You can’t do anything about this issue from server side, also 302 redirect for each request is really bad practice and it will increase page load time anyway.

If performance is your main goal and you are willing to pay extra $5 per month, this can be easily solved using Cloudflare Workers. You can remove fbclid using Worker, fetch original url without fbclid and it will be cached on the edge. Worker will serve additional requests to this url from cache instead of hitting your server despite fbclid value.

Above mentioned $5 will cover 10 million requests to your url every month and if you have more than 10 million requests monthly, you have to pay extra $0.5 for per million additional requests.

If OP and others are interested in this approach, tommorow I can share tiny code for Workers to solve this issue.

3 Likes

Thanks @nikoloz! I already shared a little piece of code for workers:

addEventListener('fetch', event => {
  let url = new URL(event.request.url)

  if (url.searchParams.has('fbclid'))
   url.searchParams.delete('fbclid')

  event.respondWith(
    fetch(url, event.request)
  )
})

I think we’d all appreciate if you shared your code as well though. The more the merrier!

3 Likes

Oh, I’m on mobile and somehow missed it. Your code looks legit, I was going to share something similar as well :+1:

Although, I might be able to reduce this cost drastically. Let me test some things tomorrow and I will report back :slight_smile:

Can you tell us what percentage of this 150M visitors are referred from Facebook?

2 Likes

Those aren’t visitors, but rather all requests made to Cloudflare for my site, including all static files (images, css, js, etc.) Regardless, I can tell you that close to 90% of my traffic comes from Facebook.

Can’t wait to hear about your findings!

In the meantime, here’s the Worker script & routes I currently use:

Worker script:

addEventListener('fetch', event => {
  let url = new URL(event.request.url)

  if (url.searchParams.has('fbclid'))
   url.searchParams.delete('fbclid')

  event.respondWith(
    fetch(url, event.request)
  )
})

Worker routes:

On: https://www.website.com/*
Off: https://www.website.com/wp-content/*

Theoretically, these routes ignore static files and only filter Worker requests with permalinks & fbclid parameter. Though adding the Off parameter did indeed drastically lower the amount of requests, it seems there are still more requests coming in than page views. So I assume something might not be quite right yet.

2 Likes

nice @janvitos

curious if you have tested the page speed metric/load time difference between

  1. doing a 301/302 redirect at Cloudflare level vs
  2. 301/302 redirect via nginx origin vs
  3. cf worker script to remove fbclid ?

you did mention a 301/302 redirect added ~80ms for you so was curious what each of these workarounds did latency wise ?

2 Likes

Indeed I tested the Cloudflare 302 and it adds around 80 ms to the request. The worker should add almost nothing (<1ms), as stated in Cloudflare’s documentation (https://developers.cloudflare.com/workers/faq/):

How fast are Workers?

Even though they’re written in JavaScript, your Workers ultimately execute as dynamically compiled machine code. Most simple Workers can be expected to respond within a millisecond, adding no measurable delay to your requests and responses.

Though, I did not test the 302 at the server level as it’s not an option that’s appealing to me at the moment. I rather do everything at the Cloudflare level since requests benefit from the CDN.

By the way, I’m using the worker now and I seem to be getting under the 10 000 000 requests per month limit (or ~ 333 333 requests per day).

4 Likes

I try few things but looks like your approach with Workers is only available option right now.

Worker routes:

On: https://www.website.com/*
Off: https://www.website.com/wp-content/*

This is smart move as well to reduce Worker requests :+1:

:+1:

1 Like

You could probably specify the route to match the query string reducing the invocations to only the ones that actually need it. Didn’t have a chance to try it, don’t know if it can be done!

2 Likes

Although you can match query string in page rules, sadly it’s not supported in Worker routes. If you try, you will get following error:

Route pattern should not have query parameters

Also there is limitation on wildcards which will make matching query parameters pointless even if they were allowed:

Route pattern may only contain wildcards at the beginning of the hostname and the end of the path

@KentonVarda @zack is it possible to remove this limitations in future?

4 Likes

By the way, I’m actually quite startled that Cloudflare didn’t participate in this thread yet. I’d be really interested in hearing your view on this Cloudflare, and I think I speak for everyone here. Thanks!

1 Like

But if someone use this method

http://www.example.com/*?fbclid=* forwarding 302 to http://www.example.com/$1

We might not be able to track user in GA. Plus Facebook might take offense they all topic getting redirected.

1 Like