This page has had its content updated on May 27, 2025 EDT by Jordan
Table of Contents
- Introduction
- Understanding Facebook Browser Client User Agent
- Real Cause for High CPU Usage fbclid Query String
- Recommend Solutions
Content Error or Suggest an Edit
Notice a grammatical error or technical inaccuracy? Let us know; we will give you credit!
Introduction
A single shared recipe post on Facebook triggered a surge in traffic that pushed a website’s server CPU usage past 200%. At first glance, the traffic appeared suspicious—user agents filled with strings like [FBAN/FBIOS;FBAV/514.0.0.47.102…] raised concerns about bots. In reality, it was legitimate traffic from Facebook’s in-app browser.
The real issue wasn’t the user agent—it was the fbclid query parameter that Facebook appends to outbound links, breaking server-side caching and forcing each request to bypass the cache and hit PHP directly. This post explores how the problem was diagnosed and resolved, covering caching strategies, Cloudflare rate limiting, and full page cache implementation with GridPane.
To preface, this was a site on GridPane behind Cloudfare.
Understanding Facebook Browser Client User Agent
You might see quite a few requests that have the user agent that looks like the following.
[FBAN/FBIOS;FBAV/514.0.0.47.102;FBBV/737212593;FBDV/)
This user-agent is actually for the Facebook App built-in browser when someone clicks on a Facebook post with an external link.
So the source of traffic is not bots scraping content, a post or page was shared on Facebook and the traffic is actual visitors visiting the site through the Facebook app built in browser.
Real Cause for High CPU Usage fbclid Query String
The reason there’s high cpu usage,the fbclid query string is breaking server cache. Each request from Facebook is triggering PHP to render the page which is costly resource wise. Here’s an example URL.
https://managingwp.io/?fbclid=IwY2xjawKixIJleHRuA2FlbQIxMQBicmlkETFxTXhZSlpyY2pXeDBKYUdjAR4td5Zuz57VNVVeaNYyNIlbjgNdHcCR0ON_1iYE-_vSJ_U1Ekj2Lo_6CEDcZw_aem_StPujIz4k6oUlS1_lN-6gQ
Recommend Solutions
1 – Server Rate Limiting
It was brought up that Server and Cloudflare Rate Limiting might be a possible solution. Which of course can help if there is bad actors, bots or scrapers sending a massive amount of requests per second.
Server Side Rate Limiting with GridPane
You can setup rate limiting at the server level if you’re using Nginx or GridPane Nginx. You can do the same with Litespeed/Openlitespeed. GridPane Openlitspeed has it enabled already and would just require tweaking.
The following article is from GridPane’s knowledge base that details how to setup custom rate limiting.
Server Side Rate Limiting with Nginx
The GridPane knowledge base article can help to craft what you need for other platforms that use Nginx, however there might be some rate limiting already in place or a similar guide on the platforms knowledge base. You can also reach out to support for whichever platform you use.
1 – Rate Limiting with Cloudflare
You can do rate limiting in Cloudflare, this means it never will hit your server and it’s all done within a UI versus config files.
Cloudflare Rate Limit Rule
The following URI paths would need to be excluded ensure that only requests for posts and pages would be rate limited and not .css and .js otherwise visiting a page or post would trigger the rate limiting due to how many assets would be loaded.
/wp-content /wp-admin /wp-includes
Cloudflare Rate Limiting Rule Expression
As you can see the rule is setup as an exclude rule, meaning all traffic is hitting the rule and then anything defined in the rules is exlcuded from being rate limited.
(not starts_with(http.request.uri.path, "/wp-content") and not starts_with(http.request.uri.path, "/wp-admin") and not starts_with(http.request.uri.path, "/wp-includes") and not cf.bot_management.verified_bot and http.request.uri.path ne "/robots.txt")
Cloudflare Rate Limiting Rule Settings
2 – Removing Query Strings (GridPane Platform)
The platform GridPane suggests remove the query string from the URL for specific queries such as fbclid, here is hte knowledge base guide.
If you implement this solution, when a requests comes in with fbclid it will rewrite the URL and remove the fblcid and redirect to the original URL effectively serving up the cached page and saving resources.
The only issue with this issue, is that the query string is removed, and if you need the query string to stay for specific actions on the page then this solution will break other functionality on yoursite.
3 – Caching Query String URL’s using URI Path
Although the previous method would work well for some, ideally it would be better to simply cache requests with fbclid and leave the query string intact.
Unfortunately the fbclid is unique to each request, and a cache item would be created for each requests effectively having no effect as dynamic requests would still filter through.
However, you can tell Nginx to use the URL path “/page-or-page-uri-path” as the cache key and not the full url “/page-or-page-uri-path/?fbclid=1f3d13” . Effectively always returning the uri-path cached page, allowing for all requests with a query string to be cached.
Unfortunately GridPane hasn’t made an article on how to utilizing this configuration due to the fact hat it requires that they update their Nginx config to support it.
4 – Cloudflare CDN Cache
One more step I suggest is full page caching at a CDN like Cloudflare using the paid Cloudflare APO or this plugin which does something similar for free.
This page has had its content updated on May 27, 2025 EDT by Jordan
Jordan Trask
With 20 years of experience in technology spanning Linux, Data Center Infrastructure, and related services and applications, Jordan consults with small, medium, and large organizations tackling technology problems and needs. With 10 years of experience in WordPress, he’s created Managing WP as a means of dumping his brain on the web.
Jordan operates LMT Solutions providing Technology Consulting Services and We Power WP for WordPress Care Plans and Support.
This page has had its content updated on May 27, 2025 EDT by Jordan