Think Cloudflare Always Speeds You Up? Not in India

The recent triangle man vs cloud man twitter debate reminded me of a Cloudflare quirk I had observed a few years ago. The issue I had observed back then (and continue to observe as of today) is this:

When I access my website hosted in India through Cloudflare, the traffic is often served from Cloudflare’s Amsterdam or Singapore data centers instead of India. This additional distance adds latency, making my site slower with Cloudflare CDN than without any CDN at all.

This time around, I decided to delve deeper to understand the behavior in detail to be more informed when evaluating CDN solutions for the teams I may work with in the future.

1. Experiment - Measuring the latency

To decipher the behavior, I conducted a bunch of experiments with one of my own static websites that is hosted on a DigitalOcean droplet in their Bangalore, India data center. And, I ran these tests from another city in India about ~1500 Km (930 miles) away.

1.1. Baseline - No CDN

First up, I measured the latency to my origin server with no CDN in place.

I could see the IP address of my DigitalOcean droplet serving this website:

And, I pinged this IP address from my laptop to grab the latency:

From the above:

• It took an average ~47 msec for a request to reach the server and for the reply to return (RTT latency).
• The latency fluctuation was minimal.

1.2. Cloudflare free plan

I moved my website to the Cloudflare free plan and repeated the steps to compare the latency.

With the change in my setup, the “Remote Address” IP address changed to a Cloudflare IP address:

Before we talk about the latency from this Cloudflare IP address, I want to highlight the Cf-Ray header in the response above. Cloudflare docs specify that Cf-Ray contains the location of the data center that served my request. So, this request originating from India, with an origin server in India was served from a data center AMS (Amsterdam)!

Based on the above details:

• The RTT latency between me and the Cloudflare instance that served my request was ~159 msec.
• At 4% standard deviation, the latency fluctuation was similar to that observed without a CDN.

Overall, the above test suggested that I had added a ~112 msec RTT latency by bringing in Cloudflare CDN!

My next question was whether this issue was specific to Cloudflare free plan or if it also affected the paid plans?

1.3. Cloudflare Pro plan

I upgraded my free plan to Pro plan (priced at $20 mo when billed anually) and then waited for about an hour before repeating the test to see if I would observe a difference in behavior.

I could now see the Cloudflare Cf-Ray header responding with a value that ends with SIN. This means, my requests were now being served from their Singapore data center. This was still not optimal since I know Cloudflare’s network page lists twenty data centers / edge locations in India including two located within 500 km (~300 miles) from where I ran these experiments.

The tests on the Cloudflare pro plan gave the following results:

• The RTT latency between me and the Cloudflare edge instance was ~207 msec.
• At 29% standard deviation, this particular test run exhibited significantly fluctuating latency values.

2. Interpreting the latency results

Dynamics of a CDN network and internet traffic are ever-changing. As a result, while I have listed results of individual tests above, I undertook multiple tests across days to avoid mismeasurements.

2.1. Results consistency

The latency tests for the three setups detailed above were undertaken twice every day across three days. In each of those instances:

• the edge instance serving the website was from AMS (Amsterdam) or SIN (Singapore) on the Cloudflare free plan
• the edge instance serving the website was from SIN (Singapore) on the Cloudflare pro plan

Across these tests:

• The average latency came out to be between 150 and 220 msec. I did not observe a change in latency when moving from free to pro plan (even though the specific experiment listed above showed a degradation on the pro plan).
• While some tests showed a greater fluctuation, others did not. This did not appear linked to free / pro plan

2.2. Not a recent issue

While I ran the detailed tests only recently, I have observed the Cf-Ray header emitting data-center locations as far as Newark, USA since 2020. Also, community reports (like this and this) dating back to 2018 suggest this behavior isn’t a recent change.

2.3. Key findings

The experiments resulted in the following key outcomes:

• Adding Cloudflare to my setup added latency when I accessed my website.
• Introducing Cloudflare also resulted in a higher latency fluctuation every now and then.
• The latency increase was not restricted to Cloudflare free plan, but was also observed with the Cloudflare Pro plan.

So, then what was at the heart of the high latency trips my requests were taking with Cloudflare in place?

3. Root cause - Peering Agreements

Scouring the internet forums helped me understand that the lack of a peering agreement between Cloudflare and the major Indian ISPs is at the heart of the high latency trouble I have been noticing.

3.1. Understanding Peering

Peering is when two networks (say, an ISP and a CDN) agree to directly exchange traffic between them. In absence of such agreements, the traffic has to be routed through multiple intermediary networks.

In this case, the absence of peering between my ISP and Cloudflare is causing the traffic to be route via Singapore or Amsterdam. The extra intermediary hops introduce additional and sometimes fluctuating latency.

3.2. Indian ISPs with problematic Cloudflare routing

I could not find a definitive list of ISPs that do not have a peering agreement with Cloudflare. But, forum discussions like this, this and this suggest that the two biggest Indian ISPs - Jio and Airtel - may not have a peering agreement with Cloudflare. Collectively, these two ISPs command over 75% Indian mobile network market share (as of Jan, 2025).

3.3. Reported Cloudflare routing issues in other countries

Again, there is no official source on this, but the users on Deutsche Telekom (and Magyar Telekom in Hungary) have frequently reported a similar routing, latency and slowness issues (see here and here).

3.4. Why no peering agreements?

The lack of peering agreements seems to stem from disagreement over the financial terms rather than any technical limitations. So, while it is difficult to know who is at fault, it is certain that users from such ISPs will experience higher latency when accessing sites hosted on Cloudflare.

4. Alternatives

Cloudflare, with its DDoS protection, Workers and no bandwidth metering is a solid offering. That stated, with the latency issues mentioned above, I would not suggest it for B2C sites targetting sizeable traffic from India.

In light of this, I conducted the same checks with sites on AWS Cloudfront, Google Cloud CDN and Akamai. These did not exhibit the routing / latency issues I observed with Cloudflare. As a result, following are the two Cloudflare CDN alternatives I would suggest to evaluate:

5. Conclusion

Absence of direct peering agreements means Cloudflare traffic in India is often routed through distant data centers in Singapore or Amsterdam. While this isn’t a technical limitation, it negatively affects the response speed of the requests originating from India.

If your audience is primarily from India, do not assume Cloudflare will improve performance. Measure the speed impact of Cloudflare on your setup and compare it with alternatives like AWS Cloudfront or Google Cloud CDN depending on your CDN needs.

Sidenote: I seek to run the latency checks on a site with Cloudflare business or enterprise plan. If you know a website on any of these plans, I’d be happy to run quick checks and update this post with details from the additional experiments.

Got a web-dev pain point?

Freelance dev & architect for B2C orgs.

What I do:

• Frontend - performance, scaling, migrations with React / Next.js
• Backend - Node.js, Koa, Knex
• Strapi, Directus CMS - customize, migrate, upgrade
• Guide tech choices - Cloud services, Frameworks, Databases
• Architectural aspects - scaling, observability

Tech I use:

Node.js, React, Next.js, Postgres, MySQL, AWS, GCP, Serverless (Lambda, CF Workers), ElasticSearch, Redis, RabbitMQ, Kibana

My Clients Include:

Let's solve your tech challenges →

Or email: punit@tezify.com

Punit Sethi

Got a web-dev pain point?

I'm a freelance dev & architect for B2C sites.

What I do:

• Frontend - performance, scaling, migrations with React / Next.js
• Backend - Node.js, Koa, Knex
• CMS - customize, migrate, upgrade Strapi, Directus CMS
• Guide tech choices - Cloud services, Frameworks, Databases
• Architectural aspects - scaling, building observability

Tech I use:

Node.js, React, Next.js, Postgres, MySQL, AWS, GCP, Serverless (Lambda, CF Workers), ElasticSearch, Redis, RabbitMQ, Kibana

My Clients include:

Let's solve your technical challenges →

Or email : punit@tezify.com