Table of contents of the article:
It is common practice when there are performance issues or you want to get a higher PageSpeed score, to rely on CloudFlare in order to have a CDN with interesting JS and CSS minification features, as well as image compression that make the page less heavy and can also allow you to meet some of the best practices recommended by Google in order to get a better score on PageSpeed tests.
Cloudflare, Inc. is an American company that provides a content delivery network, internet security services, and distributed DNS services. These services act as a reverse proxy server between website visitors and Cloudflare users' hosting providers.
Among other interesting features, that of WAF (Web Application Firewall), that of DDOS mitigation, GeoIP filtering, as well as DNS service.
It's a big company with clients like Uber, OKCupid, Fitbit, Hubspot, Gyazo, and many, many others. In short, something truly large and notable, a leader in its sector.
Offering a free plan suitable for most low/medium traffic sites , it is now common to see it used intensively even by sites that actually don't need it and could solve some speed problems directly on the server and/or application side.
By the way, it should be noted that CloudFlare keeps a bad bot filtering feature enabled by default in order to reduce the number of malicious bots and crawlers that automatically hit your site.
According to a 2016 survey by Incapsula (Imperva) , a well-known and highly effective Cloudflare alternative with more or less similar features, bad bot traffic accounts for approximately 30% of all web traffic. In other words, 30% of traffic is generated by malicious bots , and approximately the same amount by good, legitimate bots. You can read the full report here: https://www.incapsula.com/blog/bot-traffic-report-2016.html
What happens if we block the Bad Bots?
An answer full of common sense and logic could be that we will have less useless traffic on our site, less consumption of bandwidth, of resources and therefore obtain a greater degree of security.
Most likely it is a correct answer or probably so, since in fact it would be really difficult to understand what could be the usefulness of having malicious or malicious bots that roam freely on our site to make requests for pages for who knows what shady and mysterious reasons.
One thing is certain, however: if, as we have seen before, it is true that 30% of visits are generated by malicious bots, blocking bots will in fact mean blocking 30% of traffic to our site as well.
What about Google Adsense?
Theoretically, any virtuoso will state with absolute certainty that Google AdSense is completely immune to this discussion, in the sense that it has no relevance whatsoever in this context, given that Google AdSense works only and exclusively on the client side by executing Javascript scripts in the user's browser. Therefore, since bots do not have a virtual machine to execute Javascript, much less to perform actions or events, Google AdSense should be left out of this discussion as it is completely out of place.
We agree at least in part, but Google AdSense should be left aside only if activating CloudFlare did not lead to a lowering of RPM and therefore monetization.
A strange (un) fortuitous event.
Some time ago, we decided, together with the CEO of a publishing network operating across various sectors, to enable CloudFlare on all sites to optimize and improve content access and image delivery. Although we already had the usual stack optimized with Varnish and Memcache with NGINX and HTTP/2 in production, we wanted to push it further to see how the system would react. From a navigation perspective, the improvements were slight and still appreciable, but from a monetization perspective, it was a disaster. The next day, the RPM had dropped significantly and persisted for about the entire month , until we decided to remove CloudFlare and return to the original situation. A few days later, the monetization situation returned to its initial optimal values, which persisted for about a month, until we decided to reinstate CloudFlare again.
Not even to do it on purpose, same situation as before, RPM halved although the site was significantly faster and extremely fluid navigation. Why was not clear, there was no signal or motivation that could justify a lowering of revenue in that way.
We could not continue like this, therefore we have deactivated CloudFlare again and as if by magic, the usual optimal RPMs are back.
A pure chance?
The way things went, it cannot be said that it was a coincidence, especially if we consider that completely different sites were involved, both for the topics covered and for the contents, structure and peculiarities that made 5 individual sites completely different albeit from the same owner.
By searching on Google for the search terms: Cloudflare AdSense RPM you can find numerous posts from users who have encountered the same problem as us even though CloudFlare itself states that it does not negatively impact AdSense.
However, there are too many similar situations that are somehow atomically connected, as soon as CloudFlare is enabled, AdSense revenues plummet.
Is there a causal link between cause and effect or are there other types of problems that you want to attribute to CloudFlare? Are they just singular cases due to some Cloudflare problem or more likely to some Google Adsense problem? With what logic? With what criterion? Because ?
Precaution.
Since we can't provide useful answers due to insufficient evidence or even a minimal logical explanation, we'll simply ask the right questions, hoping to be helpful to anyone who decides to enable CloudFlare. Please be cautious when noting any changes in page monetization, and if you notice any inexplicable changes, as we did, don't hesitate to enable/disable caching to replicate the problem and determine the cause. If you're looking for performance improvements without impacting AdSense in any way, please contact us.
Updated July 1, 2019 : Having evaluated CloudFlare's correct behavior with no RPM reduction with various advertising networks in June, we would like to clarify that what is written in this article regarding the reduction in RPM revenue is no longer correct and valid . Readers are encouraged to independently evaluate any performance discrepancies.
