When it comes to talking about internet companies, Cloudflare is one of our most favourite internet company. The reason behind it is their unflinching goal to make the internet a faster and more secure place without hassling the user with too much technicality. Almost every Cloudflare magic is possible by turning on/off a button. This is truly magnificent. On top of that, there focus on security by providing SSL encryption to all sites, enterprise-grade firewall (in the paid plans) and bot protection are truly unmatched to anything in the industry. In the end, how can we forget the Cloudflare Free account which provides CDN caching across more than 200 cities and unlimited bandwidth? Cloudflare’s philanthropic free account gives so much power to small and medium websites that I truly have no word to thank them for it.
Now all of these being said, after using Cloudflare for a very long time understanding every bit of their system and in fact, being the co-creator of a Cloudflare focused WordPress caching plugin, WP Cloudflare Super Page Cache, I think I am in a spot to peek behind the Cloudflare curtain and see a lot of facts which are not clearly mentioned by Cloudflare on the public-facing front pages of their website. In this article, I will talk about one of the most flagship product of Cloudflare i.e. Cloudflare CDN and will show you the nitty-gritty facts that you should be aware of before using Cloudflare CDN for your websites.
Please note that the goal of this article is not to discourage you from using Cloudflare, in fact, this very website is using Cloudflare at the moment. Despite explaining the nitty-gritty nuances about Cloudflare CDN, I will recommend most of the users to use Cloudflare just because Cloudflare is not just about CDN. It is way too much more. Having your site on Cloudflare means your site is using one of the fastest free DNS in the world and not to mention all the security and optimization features you get with Cloudflare that it is simply impossible to list everything here. But still, we must need to talk about Cloudflare CDN and the possible brain fart you might get with it.
Table of Contents 📜
What is CDN & how it supposed to work?
Before going any further into the specific details about Cloudflare CDN, it is very important for you to know what a CDN is and how it is supposed to work. Content Delivery Network a.k.a. CDN is a vast network of caching servers a.k.a. Edge/POP in multiple key strategic locations spread across the globe. So, in theory, once data has been cached in the CDN network, there is no need for that requests to travel to the origin server located in a different part of the world. Instead, the request can be intercepted by your nearest CDN edge and that server will send back the cached content reducing the response time (lower TTFB) and faster access to that cached data.
So, imagine your web server is physically located in Chicago, USA and someone from Kolkata, India is visiting your website. Now in this scenario, if you are not using any CDN provider on your website, every single request needs to travel all the across the United States from India passing through multiple network hubs, facing multiple network congestions and the response generated by your server for the received request will need to come back on the same path. This will increase the response time of every single request and will also increase your website loading time.
Now on the contrary, if you would have been using a CDN on your website, the contents which are already cached by your CDN networks, those requests would have been served from the nearest CDN edge of Kolkata, India instead of sending those requests to all the way to the USA. Due to this fact, the requests being served via CDN would have super low response time and this would lead to a much faster webpage loading experience.
Cloudflare DNS Approach: Anycast vs Unicast
If you decided to use the Cloudflare CDN network which is one of the largest CDN networks in the world with more than 200 CDN edge locations, one thing you must have to use is the Cloudflare DNS system. Your domain nameservers would be pointed to Cloudflare Nameserver and your DNS will be managed by Cloudflare. On paper and in reality, Cloudflare DNS is the fastest free DNS in the world. Not only that but also to use Cloudflare goodies like CDN, you also need to enable the orange cloud (Cloudflare Proxy) for those DNS records.
One of the major advantages of enabling Cloudflare Proxy (orange cloud) for your DNS entries is that no one in the open internet will ever know the actual origin server IP and hence they cannot send massive DDOS attacks directly to your origin server IP. Instead, if anyone queries your website to find out your server IP, they will always see a Cloudflare IP. Now if anyone does perform a massive DDOS attack against your website, Cloudflare will easily detect and protect your website against such DDOS attacks.
But there is also another side of this Cloudflare proxy story. That is their Anycast network architecture. What this means is no matter from which location you query a website behind Cloudflare proxy, you will always see the exact same IP address across the whole world.
On the other hand, if Cloudflare DNS would have used a Unicast network architecture, you would have seen different IP across different locations. What this means is that within a unicast network, when you query a hostname, it will show you the IP address of the CDN edge nearest to that location. So, just by looking at the IP address, you can see which CDN edge is handling and responding to the request. For example, take a look at the screenshot below where the hostname is using BunnyCDN which uses a unicast network and you can easily see that across different location the request is being served from different BunnyCDN network edges.
Now despite Anycast networks having many benefits over Unicast networks, one of the major disadvantages of an anycast network is not advertising the actual CDN edge IPs to the public internet. This problem can be clearly felt while using Cloudflare CDN. Cloudflare has no access to which Cloudflare CDN edge your data will be served from and instead it is solely dependent on the ISP and their peering network.
Cloudflare CDN Routing Anomaly
If you are using Cloudflare CDN personally or accessing a website that uses Cloudflare, you might often find that the CDN cached contents of the webpages are being served NOT from your nearest CDN edge but from a place quite far from you. According to Cloudflare, they do not discriminate CDN edges based on which plan you are on. So, whether you are on a Free, Pro, Business or Enterprise plan, all of the 200+ CDN edges Cloudflare has is actually open for everyone. But then again it is not that straight forward and there are tons of nuances there that you need to understand in detail. So, let’s get into them.
While using Cloudflare CDN, your ISP decides which CDN Edge to connect
This is one of the major disadvantages of Cloudflare CDN in my honest opinion. As Cloudflare uses Anycast network and they themselves do not advertise the IP address of where to route the traffic when it is coming from Kolkata, India or Darwin, Australia and instead provide a common IP to everyone, it is up to the ISP about where to route that traffic based on the peering they have with Cloudflare datacenters.
Some major national ISPs might have great peering with all the Cloudflare CDN edges in your country whereas some smaller ISPs might not have such good peering. So, it is quite common to see that when I am sending a request from Kolkata, India where Cloudflare does have a CDN edge, I might see the requests either getting served from Mumbai, India or even from my neighbouring countries like France, Japan, Singapore etc.
In fact, if you contact Cloudflare Support about that, they will simply not take any responsibility in this part and will always put the blame on your ISP saying that they don’t have any control over ISP routing and they don’t know why your ISP is routing your request to that place. They will even ask you to contact the network team of your ISP and report the issue to them. Which is honestly hilarious to me mostly because one of the major reason behind this problem is Cloudflare Anycast network. If Cloudflare would have used a Unicast network architecture, this problem would have never occurred in the first place. As in that situation, Cloudflare would be the one to advertise the exact CDN edge IP of where the requests need to be sent.
I don’t know about other parts of the world, but here in India, no general user can send a mail or talk directly to the network team of any ISP. Whereas considering the scale and scope of Cloudflare, they might have a way to reach out to the network team of ISPs and resolve the problem but I honestly don’t see that intention in them.
Cloudflare Account-Based IP Pool: Another piece of puzzle
Each domain (Cloudflare Zones) that you add onto Cloudflare gets assigned to an IP pool (IPv4 & IPv6) based on their account tier. So, a domain that is using Cloudflare Free might be on a certain IP pool whereas domains that are in Pro, Business and Enterprise accounts will have different IP pools. Now one thing that I have noticed frequently is that any website which is using Cloudflare Free plan and is in that IP range, will always be served from a faraway place via Cloudflare CDN (especially over IPv6). But as soon as that account is upgraded and the IP ranges associated with that account changes, the contents starts getting delivered from much closer CDN edges.
Now do note that I’ve tested and witnessed these things on an ISP that has great peering with almost all Cloudflare CDN edges in my country, yet each time, I try to access a site on Cloudflare Free plan over IPv6, the data is being served from a CDN edge in France. When accessing over IPv4, the data is getting server by Mumbai, India or someplace in Japan. All of these, despite my ISP, having a great peering with all Cloudflare edges in my country.
Your DNS Resolver might be the Culprit too
Another wired thing I have noticed is that when I run the tests on the default DNS resolver given by my ISP, responses seem to be served from Cloudflare CDN edges much nearer to me or in my country. On the other hand, when I switch to the so-called faster DNS resolvers like Google DNS (184.108.40.206) or Cloudflare 220.127.116.11, sometimes (not always) I get responses from Cloudflare CDN edges that are a little farther from me. So, even the DNS resolver you are using might also play a role in which Cloudflare CDN edge will be serving your request.
Taking a deeper look 🧐
As you start thinking deeper into this matter it becomes very wired when you ask the question that why would an ISP based in India, having great peering with all the Cloudflare CDN edges present in India will send the request all the way across France (for sites on Cloudflare Free Plan over IPv6) and not send it to the many CDN edges Cloudflare already have in the country? The cost of that will be way minimal compared to sending the request to France. Yet when you upgrade the same account to Cloudflare Pro, Business or Enterprise, it started getting served from CDN edges within the country.
There is even more drama left on this. If I access a website on Cloudflare Free plan over IPv4, the data will get served either from Mumbai, India or from NRT, Japan but never from Kolkata, India CDN edge. Over IPv6, the data will always be served from France.
When accessing a website on Cloudflare Pro plan (over both IPv4 & IPv6) from my city Kolkata, India (CCU), I will see the request is being served from the CDN edge present in my city itself, so the responses are super fast.
Now if I request another website that is on the Cloudflare Business plan (over both IPv4 & IPv6), I will see that site is being served from again CCU, which is the CDN edge present in my city.
Finally, if I check a site on the Cloudflare Enterprise plan, the story suddenly takes another turn. Over on IPv4, it serves the data from my nearest CDN edge i.e. CCU while on IPv6, it is getting served from Mumbai, India (BOM) which is far away from my location and hence the response time is higher compared to CCU.
Now when I run the exact same tests from some place in my neighboring state (Jharkhand, India) while using the exact same ISP with exact same settings, what I found was:
- Website on Cloudflare Free plan is still being served from MRS (France) over IPv6 and Mumbai, India (BOM) over IPv4.
- Website on Cloudflare Pro plan is being served from Mumbai, India (BOM) despite CCU being the nearest CDN edge over both IPv4 & IPv6.
- Website on Cloudflare Business plan is being served from CCU both over IPv4 and IPv6, as it should be.
- Website on Cloudflare Enterprise plan is being served from CCU (over IPv4) and BOM (over IPv6).
As you can see the result varies across plan and IP ranges. When I informed this matter to the Cloudflare Support team, they again blamed the ISP and their routing as expected. It seems Cloudflare is telling the world they have no partiality across accounts in different tiers and each account can use all of their CDN edges. But in reality that never seems to be the case as Cloudflare has given the responsibility of selecting your nearest CDN edges to the ISPs.
If Cloudflare would have used a Unicast network they could have easily taken this burden off from the ISPs to themselves advertising the exact CDN edge IP to send the request to, but they will not do that and will stick to the current Anycast system. So, it is up to the ISP to have good peering with all the Cloudflare CDN edges in your country, track from where you are sending the request and then hopefully send it to your nearest Cloudflare CDN edge. But if that doesn’t happen, you can’t blame Cloudflare for not serving the request from your nearest Cloudflare CDN edges.
This problem becomes even more evident when you look outside of the USA & Europe. As in these places, all ISPs might have a great connection with all Cloudflare CDN edges within their country and then route the request responsibly to your nearest Cloudflare CDN edge. But when you look inside the countries like India, Bangladesh and many others who have many ISP, some are big national level ISP (who might have good peering with your nearest Cloudflare CDN edges) and there are local ISPs who don’t have good peering with Cloudflare CDN edges. Now Cloudflare being a fully Anycast network, you are at the mercy of your ISP to hopefully serve the contents from your nearest Cloudflare CDN edges and you can’t do anything about it.
Real-World Test Results 👨💻
What I have described above, I know many of you nerd minded people like me would be craving for some actual real-world test data. So, here it is for you to see the depth of this matter. Here are some key details about my testing location and ISP:
- Testing Location: Kolkata, India
- Expected Cloudflare CDN edge: CCU
- ISP Name: Reliance Jio Infocomm Ltd.
- DNS Resolver: Default resolver that is provided by the ISP
Now when I visit
/cdn-cgi/trace of each domain names that are using Cloudflare, using the command
curl https://<domain-name>/cdn-cgi/trace --ipv4 for checking response over IPv4 and
curl https://<domain-name>/cdn-cgi/trace --ipv6 for checking the response over IPv6, I will see the name of the Cloudflare CDN edges that are responding to the request. Here is the result that I got (notice the value of colo in the response).
Cloudflare CDN edge short names are actually the IATA airport code of that city. You can use a website like World Airport Codes to search using the IATA code and see the exact location.
Testing Cloudflare Free Account
> curl https://nisdkolkata.com/cdn-cgi/trace --ipv4 fl=215f8 h=nisdkolkata.com ip=4X.XX.X.X ts=1614348984.014 visit_scheme=https uag=curl/7.68.0 colo=BOM http=http/2 loc=IN tls=TLSv1.3 sni=plaintext warp=off gateway=off
Sometimes it also gave the following result:
> curl https://nisdkolkata.com/cdn-cgi/trace --ipv4 fl=22f307 h=nisdkolkata.com ip=4X.XX.X.X ts=1614349334.217 visit_scheme=https uag=curl/7.68.0 colo=NRT http=http/2 loc=IN tls=TLSv1.3 sni=plaintext warp=off gateway=off
So, as you can see when testing a Cloudflare Free account over IPv4, the request is sometimes get handled by the Cloudflare CDN edge located at BOM, India (still the opposite part of my country compared to where I am) and sometimes it gets served by NRT, Japan Cloudflare CDN edge, which is completely a different country. So, the response time is lower when data is served by BOM edge compared NRT edge.
> curl https://nisdkolkata.com/cdn-cgi/trace --ipv6 fl=49f76 h=nisdkolkata.com ip=2XXX:XXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX ts=1614349426.463 visit_scheme=https uag=curl/7.68.0 colo=MRS http=http/2 loc=IN tls=TLSv1.3 sni=plaintext warp=off gateway=off
When testing over IPv6, the requests will always consistently get served via the Cloudflare CDN edge MRS, France. So, the response time is quite high compared to when the request was getting served via BOM, India edge over IPv4.
Testing Cloudflare Pro Account
> curl https://theecohub.ca/cdn-cgi/trace --ipv4 fl=217f1 h=theecohub.ca ip=4X.XX.X.X ts=1614350838.444 visit_scheme=https uag=curl/7.68.0 colo=CCU http=http/2 loc=IN tls=TLSv1.3 sni=plaintext warp=off gateway=off
In the case of accounts on Cloudflare Pro, the data is always being served from the Cloudflare CDN edge present in Kolkata, India (CCU), which is literally my city and from where we expected all the data to be served in the first place as it is the nearest edge to me. Due to this, the response time is super low.
> curl https://theecohub.ca/cdn-cgi/trace --ipv6 fl=217f1 h=theecohub.ca ip=2XXX:XXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX ts=1614351151.413 visit_scheme=https uag=curl/7.68.0 colo=CCU http=http/2 loc=IN tls=TLSv1.3 sni=plaintext warp=off gateway=off
As you can see for accounts in Cloudflare Pro, even over IPv6, the data is consistently being served from my nearest Cloudflare CDN edge: Kolkata, India (CCU) exactly like it was performing over IPv4.
Testing Cloudflare Business Account
> curl https://www.crunchbase.com/cdn-cgi/trace --ipv4 fl=217f12 h=www.crunchbase.com ip=4X.XX.X.X ts=1614351405.229 visit_scheme=https uag=curl/7.68.0 colo=CCU http=http/2 loc=IN tls=TLSv1.3 sni=plaintext warp=off gateway=off
So, even for accounts on the Cloudflare Business plan, when the site is accessed over IPv4, it is being served from my nearest Cloudflare CDN edge, CCU, India; exactly like Cloudflare Pro accounts.
> curl https://www.crunchbase.com/cdn-cgi/trace --ipv6 fl=217f19 h=www.crunchbase.com ip=2XXX:XXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX ts=1614351642.737 visit_scheme=https uag=curl/7.68.0 colo=CCU http=http/2 loc=IN tls=TLSv1.3 sni=plaintext warp=off gateway=off
We again get to see a very similar story like Cloudflare Pro accounts. Even over IPv6, sites on the Cloudflare Business plan are constantly being served from my nearest Cloudflare CDN edge CCU, India.
Testing Cloudflare Enterprise Account
> curl https://www.cloudflare.com/cdn-cgi/trace --ipv4 fl=217f17 h=www.cloudflare.com ip=4X.XX.X.X ts=1614351908.49 visit_scheme=https uag=curl/7.68.0 colo=CCU http=http/2 loc=IN tls=TLSv1.3 sni=plaintext warp=off gateway=off
As you can see, over IPv4, domains using Cloudflare Enterprise plan are also constantly getting served from my nearest Cloudflare CDN edge CCU, India just like domains using Cloudflare Pro or Business plans.
> curl https://www.cloudflare.com/cdn-cgi/trace --ipv6 fl=202f118 h=www.cloudflare.com ip=2XXX:XXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX ts=1614352061.117 visit_scheme=https uag=curl/7.68.0 colo=BOM http=http/2 loc=IN tls=TLSv1.3 sni=plaintext warp=off gateway=off
This is where the story takes a complete turn when you access the website over IPv6. As you can see the domain being in the highest tier Cloudflare plan i.e. Cloudflare Enterprise, the data is getting served from Mumbai, India (BOM) which is present in the opposite part of the country. Due to this, the response time is also higher than the response time over IPv4 where the data was getting served from my nearest Cloudflare CDN edge.
What about the Traceroute?
Any of you who might be interested in seeing the traceroute of these domains over both IPv4 and IPv6, feel free to take a look at the screenshot below containing the Traceroute of the above mentioned domains. 🙂
So, it seems Cloudflare team were not lying when they said it is up to the ISP to determine where they would like to route a specific IP range despite there being Cloudflare CDN edges much closer to you. Unfortunately neither you nor Cloudflare can do anything about it due to the Anycast network architecture they uses.
Another important thing to note here is that though I’ve shown the above tests both over IPv4 and IPv6, Cloudflare users who are using Free, Pro or Business plans can’t turn off IPv6 mode inside their Cloudflare dashboard even if they want to stick with just IPv4 for possibly better routing. The only way they can do it is by using the Cloudflare API. This feature via dashboard is only available in the Cloudflare Enterprise plan.
Moreover, though I’ve only shown one domain from each Cloudflare account category, I’ve tested the same with several domains in the same category and the result is exactly the same. I’ve also run the exact same test you see above across different DNS resolvers like Google 18.104.22.168 and Cloudfare 22.214.171.124. So, there is absolutely no point in increasing the length of the article by showing the same thing over and over. But if you are interested in seeing the result across different DNS resolvers, check out this GitHub Gist.
Cloudflare Cache Creation, Replication & Storage
As we have already talked about Cloudflare CDN routing anomalies in detail and by now I hope you have a detailed understanding of how it works and what to expect from it, now it is time to talk about Cloudflare CDN cache itself. There are many small things you need to be aware of when you are using Cloudflare to cache your content and using their CDN to serve them.
Cloudflare Cache Creation & Storage
Due to the scale and volume Cloudflare operates in, they employ a very specific kind of caching mechanism to identify what to cache and how long to keep the cache in the CDN. Before we get into any further specifics, first take a look at the below diagram which clearly depicts how Cloudflare cache works.
As you can see in the above diagram when a user makes a request for an item that is already not present in the Cloudflare CDN cache, it first pulls it from the origin server and then stores it into the memory of the CDN server that made the request. While staying in this Transient Cache, if that newly cached content does not get accessed by other users a certain number of time within a certain period of time (both of which are not explicitly specified by Cloudflare) the cache gets automatically deleted from that CDN edge no matter what
s-maxage value you have specified in your cache-control response header. That header simply tells Cloudflare for how long you are intending to cache the content in Cloudflare’s CDN servers before it gets expired. But this does not mean Cloudflare will keep that content cached in their CDN servers for the time you have specified.
On the other hand, if the cached content gets accessed many multiple number of times from the Transient Cache of that CDN edge which cached the content, the cached content gets promoted to the SSD based Permanent Cache where it lives for much longer than the Transient Cache. But just because a cached item has been transferred to Permanente Cache doesn’t mean that it will live there forever. If that content will suddenly stop getting accessed by many people Cloudflare will delete the cache from the disk to clear room for other cached contents are are frequently getting accessed by users.
Now as Cloudflare does not specify the exact check that they employ in the system so there is no way to know for sure that upgrading your account to a paid Cloudflare Plan will give it a little longer life in Transient Cache before getting deleted, if the content is not getting accessed a lot. During my testing I didn’t find any massive lifespan difference across the accounts but it seems Cloudflare Paid accounts does have a little extra lifespan in Transient Cache than the Free plans (not 100% sure).
So, if you have a small website that does not have heavy traffic but you would like Cloudflare CDN to keep your content cached for as long as you have asked them to, there is no way that is going to happen; even if you upgrade to a paid Cloudflare plan. Hence, upgrading your Cloudflare account just for longer cache life for less accessed contents makes no sense.
I know this is very unsettling especially for the paid Cloudflare users who pays a good amount of money each month to Cloudflare without knowing their cached data can be deleted from any Cloudflare CDN edge if it doesn’t have constant traffic to it. On the other hand companies like BunnyCDN does not delete anything from their CDN cache unless you purge them yourselves or they get expired after the caching time specified by you. Unfortunately that is not the case with Cloudflare.
Personally, I think Cloudflare does this because of the exabyte amount of data they handle every day. If they do not delete cached items which are not being accessed via that CDN edge for some specific amount of time, they will soon run out of hard drives to store all the cached contents and also run out of data centre space. Whereas employing this technique ensures that all the Cloudflare CDN edges only hold the data that is constantly being accessed by users. Also not to forget, thanks to these unique techniques millions of users get to use the Cloudflare Free plan. Otherwise, if they would have stored all cached contents for the long term, someone had to pay for all those storage costs.
I don’t know if Cloudflare will ever do this, but I think the users who are looking for a consistent long term cache for their content irrespective of whether or not that content is constantly being accessed by users, Cloudflare can charge some extra monthly fees to cover the extra storage costs for those users only. Otherwise, if you have a small website with low traffic and you were considering Cloudflare just for their CDN feature, I think you are better of using some alternate CDN like BunnyCDN which will satisfy all of your CDN needs, but there is no Free plan.
Cloudflare Cache Replication
Now as you have leant how Cloudflare creates and stores cache, let’s talking about another side of the coin, cache replication. With more than 200 CDN edges across the world, one of the most common question users have is if the content is cached by one Cloudflare CDN edge, does it automatically gets cached by all the CDN edges in the Cloudflare network? The answer is NO.
Currently, when you make a request for a certain asset it will only get cached by the Cloudflare CDN edge that intercepted that request. So, if another user from a different part of the world requests the exact same asset, the cache journey for that CDN edge will start fresh. This means that CDN edge will first fetch it from the origin server, put it in the Transient Cache, check if enough request is coming for that request to that CDN edge, if yes then transfer the cache to Permanent Cache or delete it from the CDN cache. This cycle will continue for every single Cloudflare CDN edge.
Now there are two ways to get around this problem. One involving Cloudflare Worker & KV storage and the other involving Cloudflare Argo. But the sad part is for a moderate blog or website both of these will cost quite a bit of extra money on top of your existing Cloudflare plan. Let’s talk about them briefly.
Cloudflare Worker & KV
Cloudflare Worker is a revolutionary technology introduced by Cloudflare which allows you to run custom logic on every CDN edge. So, you can handle the request at Cloudflare CDN edge servers exactly the way you want. I’ve written an article about Cloudflare Workers and showing it’s power, take a look into it to know more about Cloudflare Workers.
KV on the other hand is a Key – Value storage system to work with Cloudflare Workers. So, you can actually write a Cloudflare Worker script to store your cached contents both at Cloudflare CDN servers as well as in KV. Now one of the best parts about Cloudflare Workers & KV is that as soon as you deploy a Worker or add a data to the KV, both the worker code and KV data gets automatically replicated across all the Cloudflare CDN edges.
So, if a user is requesting for an asset which is not yet been cached by that specific Cloudflare CDN edge, it can instantly pull the data from the KV storage and send it to the user along with caching internally in the CDN. In this way any item added to your KV storage is always available across every single Cloudflare CDN edge. In fact this is the same logic that is used by Cloudflare Automatic Platform Optimization (APO).
Cloudflare Argo Smart Routing & Smarter Tiered Cache
Cloudflare Argo is another revolutionary product by the Cloudflare team. The Argo Smart Routing works between the origin server and Cloudflare CDN edge whereas the Argo Smarter Tiered Cache works between the users and the Cloudflare CDN. Once you enable Cloudflare Argo, the systems will use artificial intelligence (AI) to find the fastest route to reach the origin server by a Cloudflare CDN edge.
Normally all requests on the internet follow a specific route to go from Point A to Point B determined by all the router and switched that creates the internet. But as all request on the same path follows the exact same route, often there are congestions in certain pockets of the internet. Argo Smart Routing uses AI to determine the fastest and encrypted path to reach the origin server. Imagine it as Google Maps for your Cloudflare CDN edges to send requests to the origin server. By doing this the latency between Cloudflare CDN edges and the origin servers gets reduced a lot. There is a great blog post by the Cloudflare team going in-depth about Argo, if you are interested, you much check it out.
Now on the other side of smart routing is Argo Smarter Tiered Cache. Here Cloudflare basically divides all of its CDN edges into separate tiers. So, among all the 200+ CDN edges some CDN edges get labelled as Upper Tier and some as Lower Tier. Now the logic here is that once a data is cached by any of the upper-tier CDN edges if any user is requesting for an asset and that request is served by a lower-tier CDN edge who doesn’t have that data cached into its system, instead of that CDN edge sending the request to the origin server, that request will be sent to the upper-tier CDN edge who already have that data cached into its system and fetch it from there. No need to say, this transaction is super fast as the communication happens inside Cloudflare’s own network.
Though both the option is very promising but one of the important things to note here is that both Cloudflare Worker & KV and Agro costs separately. In fact, for a small to medium site Argo can cost a lot of money as it will charge you based on your bandwidth (both cached + uncashed). On the other hand Worker & KV might cost a bit less (it also has a generous free tier) but the complexity of deployment and cost for KV read/writes can easily increase as your site grows.
I’ve personally sent a feature request to the Cloudflare Cache team to introduce auto cache replication across the whole CDN network just by turning on a button inside the Cloudflare dashboard, something similar to BunnyCDN Origin Shield and Perma-Cache. But I am not sure if they will ever do it. In fact, if you just look at the CDN aspect it does feel like BunnyCDN has many groundbreaking features which are seriously missing in Cloudflare CDN. I do understand that Cloudflare cannot provide these features to the Free accounts and I am not asking them to do that. But when seeing paid Cloudflare accounts lacking these amazing features provided by the competitors, it really feels sad. 😔
In the end, I must say that when thinking about Cloudflare, it is really hard to compare them directly with a single compotator as they do so many things for the webmasters across the world, making their life easier while also making the internet a more secure and faster place. Cloudflare is not just a CDN provider, it is just one of their products. Cloudflare does so much more than just providing CDN, like providing you with the fastest free DNS in the world, giving your website SSL security just with a flick on a button, giving optimization system like Rocket Loader, HTTP 3 support without any server configuration, image hotlinking protection, email protection, DDOS protection and so much more.
On top of that if you have a paid Cloudflare account, just with the Pro plan of 20$/mo you get on the fly image optimization with next-gen image format support, Web Application Firewall (WAF), privacy focus user analytics, cache analytics and so much more. So, when you look at Cloudflare as a whole, I think there cannot be any better choice than Cloudflare.
But if you focus on just the CDN part of their offering and unless you have a very high traffic website where users from across the world are accessing all of your cached content all the time or you are looking for a CDN feature that is not offered by Cloudflare without any extra special cost or maybe you are just frustrated with Cloudflare’s Anycast network model and depending on the ISP to serve your cached data from your nearest CDN edge; BunnyCDN will be your best choice as they are soon going to introduce their own Unicast DNS system which works flawlessly with BunnyCDN and giving you the peace of mind that the cached content will always be served from the user’s nearest CDN edge no matter what ISP they use.
On the other hand, the only way Cloudflare can fix their CDN routing issue is by working closely with every single ISP around the world to ensure user data always gets served from the user’s nearest CDN edge. But honestly, this thought is impractical and I don’t expect Cloudflare to do any such thing as there are so many ISPs (small & big) across the world. Also, Cloudflare is not going to shift away from their Anycast system, so maybe this anomaly will never get resolved. We can only hope for it. 🤞