I would love to see Wasmer Edge in the next comparison!

A summary for the lazy readers:

  * Cloudflare workers outperforms the rest by a big margin (~80ms avg)
  * Fly.io cold starts are not great for the Hono use case (~1.5s avg)
  * Koyeb wraps the requests behind Cloudflare to optimize latency (150ms best case)
  * Railway localized the app in one region (80ms best case, ~400ms rest)
  * Render has some challenges scaling from cold (~600ms avg)

In my opinion, this shows that all platform providers that uses Docker containers under the hood (Fly, Koyeb, Railway, Render) only achieve good cold starts by never shutting down the app. The ones that they do, can only achieve ~600ms startup times at best.

I was surprised to see such miserable measured latency to Fly, but then I saw this note:

>The primary region of our server is Amsterdam, and the fly instances is getting paused after a period of inactivity.

After they configured Fly to run nonstop, it outperformed everyone by 3x. But it seems like they're running the measurement from Fly's infrastructure, which biases the results in Fly's favor.

Also weird that they report p75, p90, p95, p99, but not median.

Very odd that AWS Lambda/Google Cloud Functions weren't tested. Those CF numbers are impressive though, they beat Lambda cold start by a mile.

(Render CEO) Our free services are meant for personal hobby projects that don't need to stay up all the time; I'd love to see tests (and uptime monitoring) for the $7/mo server on Render. Happy to give you credits if it helps.

OP's note about Johannesburg's latency is something I've noticed over the past few weeks in particular. Our servers are hosted in South Africa, yet accessing most of our sites and services from within South Africa causes traffic to be re-routed via other nodes, mostly London (LHR). This is easy to verify by appending cdn-cgi/trace onto a Cloudflare-proxied domain.

Something is definitely up with Cloudflare's Johannesburg data centre. On particularly bad days, TTFB routinely reaches 1-3 seconds. Bypassing Cloudflare immediately drops this to sub 100ms.

In the past, I would have emailed support@cloudflare.com, but it seems that this channel is no longer available for free tier users. What is the recommended approach these days for reporting issues such as this?

I feel like this title is misleading compared to the original article. (cc @dang) Fly.io without cold starts (which is a one-line configuration change) is 2x faster than Cloudflare Workers.

On which cloudflare plan though? On free plan, eu visits are constantly routed through Estonia and Russia in our case, causing about 1-5 sec ttfb

im curious what the results would be with a more production-like app

e.g. if you add prisma connecting to postgres, presumably there's extra latency to create the client. for the fly app, you have a server reusing the client while it's warm. presumably for the cloudflare worker, you're recreating the client per request, but im not 100% on that. how would the latency change then for cold vs warm, and on the other platforms?

I’d be curious how Deno Deploy does.

I wonder how much the open status server allocation plays a role in this case - they tested from 6 different location but its not clear if fpr example openstatus servers are in closer datacenters.

Curious what people think of this. Seems like a huge difference. Much larger than I expected.

Those Fly.io p99 latencies are atrocious. 2.6s P99 compared to CloudFlare 1.0s. Neither one seems particularly great at first glance, but the CloudFlare worker latency does seem on par with Lambda from previous experience (I have not tested Lambda@Edge or CloudFront Functions).