It’s good that CF is actually trying to improve its platform instead of blaming others for smearing its product. Still, the breakneck pace is a mixed blessing. Things change so fast it’s hard to keep up, and launches often outrun polish. The R2 Data Catalog still lacks Iceberg v3 support; Wrangler has shifted dramatically in just a few months; and Pages seems to be on the way out, leaving me with Workers Assets that are painful to migrate. Configs that worked in Wrangler 3 didn’t carry over cleanly to Wrangler 4, and it feels like Wrangler 5 will introduce yet another interaction model.
CF used to encouraged people to move to Workers instead of using Pages. They recently removed the message in their landing page that said so (just checked, you could visit Wayback Machine to verify), so I guess Pages will still be available anyway. Btw the best thing that Pages gives out is allowing people to use different domain from another domain registry when Workers force user move their domain to CF.
> Workers will receive the focus of Cloudflare's development efforts going forwards, so we therefore are recommending using Cloudflare Workers over Cloudflare Pages for any new projects
Fun thing is that this started because somebody claimed that Cloudflare is faster than Vercel. Then somebody who knows what they are doing did benchmarks that showed the opposite. And then worked with Cloudflare to make it faster
I am in the process of porting my web app[1] from NextJS hosted at Vercel to Astro/React hosted at Cloudflare, and something that particularly surprises me is that I can render a web app on every request at “the edge” and have response times of 100-200ms. That is almost as fast as fully static pages.
I have also definitely noticed an improvement in Cloudflare Worker over the last few weeks; cold starts have practically disappeared, and they are significantly more stable in terms of response times.
Hello! How are you collecting your edge workload to the database? Are you using cloudflare’s database?
I’ve wanted to try out this edge hosting thing but because of the amount of round trips involved between the application and the database, the application performs worse on the edge.
The database is hosted on Railway. I have enabled Smart Placement that should, depending on request time, automatically use an endpoint closer to the database to speed it up. When requesting a route that includes a database request, the response time on the US east coast is around 200ms and closer to 1000ms in Denmark. I am hoping that the Smart Placement will work better when I go live with the app (still in beta) and that it mainly needs more traffic to calculate optimal endpoint placement.
Have you given Hyperdrive[0] a try? In theory, it should improve performance in your use case where you have a central database (Railway) being connected to from the Edge (your Workers).
It moves the DB connection logic closer to your Workers, pools connections, and can also cache queries.
(Disclaimer: I work for Cloudflare, but on an unrelated team. Not personally used Hyperdrive, but heard good things!)
Well, that only speaks better of higher ups who (a) offered you a space to that and (b) didn't micro managed you into something, like vercels hate piece.
Speaking of `JSON` functions that can have drastic performance differences, V8 blog[0] recently had a post about improving `JSON.stringify` performance when you don't pass a `replacer` function. Some of the most used functions with performance pitfalls that are easy to trip into.
Reading this really makes me wonder how does Chrome actually optimize for the plethora of devices running v8 (under Chrome). Definitely involves tricky decisions to be taken for great performance.
Keep in mind that Theo said the Vanilla benchmark was running too fast so he made it "way way slower" so 4x is not representative of a direct comparison
cf has to hire people with obsession not benchwarmers that only activate when someone yells at them because of a twitter argument. there i said it.
vercel only exists because cf got lazy.
huge fan of CF, and if cloudflare had the attention to details that vercel has, there would be no vercel. fullstop.
CFs docs, repos, video content but also code samples, sdks (lol all the mcp stuff) usually is subpar to vercel's.
its really annoying that nextjs has to be forked and/or patched to work on cloudflare.
Overall I'm quite positive towards core Cloudflare products like Tunnels, Workers, R2, KV etc, but a lot of newer products are often either thoroughly broken (e.g. Cloudflare AI) or unusable due to insufficient documentation (e.g. Email Routing).
After being burned a few times, I think I'm going to ignore any new Cloudflare product for 12 months after stable release. If their products worked as advertised, I'd be willing to pay considerably more. I think their commitment to the free tier is hamstringing them a little bit.
It’s good that CF is actually trying to improve its platform instead of blaming others for smearing its product. Still, the breakneck pace is a mixed blessing. Things change so fast it’s hard to keep up, and launches often outrun polish. The R2 Data Catalog still lacks Iceberg v3 support; Wrangler has shifted dramatically in just a few months; and Pages seems to be on the way out, leaving me with Workers Assets that are painful to migrate. Configs that worked in Wrangler 3 didn’t carry over cleanly to Wrangler 4, and it feels like Wrangler 5 will introduce yet another interaction model.
Where do you see that "pages seems to be on the way out"? I use pages for a few projects...
CF used to encouraged people to move to Workers instead of using Pages. They recently removed the message in their landing page that said so (just checked, you could visit Wayback Machine to verify), so I guess Pages will still be available anyway. Btw the best thing that Pages gives out is allowing people to use different domain from another domain registry when Workers force user move their domain to CF.
Workers require you to use CF as a domain registry? Where is that written and what possible reason do they give for it? That's quite an imposition.
I didn't find it hard to migrate. Pages are workers, so might as well just use a worker.
It's hard if you don't use a JavaScript based SSG, well I didn't find how to do it with Hugo so I'll stay in cloudfare pages
The migration guide contains this:
> Workers will receive the focus of Cloudflare's development efforts going forwards, so we therefore are recommending using Cloudflare Workers over Cloudflare Pages for any new projects
https://developers.cloudflare.com/workers/static-assets/migr...
Fun thing is that this started because somebody claimed that Cloudflare is faster than Vercel. Then somebody who knows what they are doing did benchmarks that showed the opposite. And then worked with Cloudflare to make it faster
I am in the process of porting my web app[1] from NextJS hosted at Vercel to Astro/React hosted at Cloudflare, and something that particularly surprises me is that I can render a web app on every request at “the edge” and have response times of 100-200ms. That is almost as fast as fully static pages.
I have also definitely noticed an improvement in Cloudflare Worker over the last few weeks; cold starts have practically disappeared, and they are significantly more stable in terms of response times.
[1]: https://app.sqlai.ai/
Hello! How are you collecting your edge workload to the database? Are you using cloudflare’s database?
I’ve wanted to try out this edge hosting thing but because of the amount of round trips involved between the application and the database, the application performs worse on the edge.
Thanks!
The database is hosted on Railway. I have enabled Smart Placement that should, depending on request time, automatically use an endpoint closer to the database to speed it up. When requesting a route that includes a database request, the response time on the US east coast is around 200ms and closer to 1000ms in Denmark. I am hoping that the Smart Placement will work better when I go live with the app (still in beta) and that it mainly needs more traffic to calculate optimal endpoint placement.
Have you given Hyperdrive[0] a try? In theory, it should improve performance in your use case where you have a central database (Railway) being connected to from the Edge (your Workers).
It moves the DB connection logic closer to your Workers, pools connections, and can also cache queries.
(Disclaimer: I work for Cloudflare, but on an unrelated team. Not personally used Hyperdrive, but heard good things!)
[0]: https://developers.cloudflare.com/hyperdrive/
So a remote, authenticated DB connection over the internet? How many db queries per page generation does that generally work out as?
I really appreciated that the tone of the article is about what can be improved, rather than dunking on the competition.
That's what everything is about!
PS: It's awesome to see improvements on the OpenNext implementation, that other providers can also reuse
This is great PR. Well done to whoever orchestrated that post.
Thanks! This was 100% produced and orchestrated by engineers on the Workers team (including me).
Well, that only speaks better of higher ups who (a) offered you a space to that and (b) didn't micro managed you into something, like vercels hate piece.
Again, well played, nice fix, nice writeup.
Blog run by the engineering team. I wouldn’t even know how to veto a post if I wanted to. Not in our DNA.
Is there any secret beyond what I’m guessing is “hire the right people and then trust them”?
My take from this article is that SvelteKit is crazy fast and Next.js is a snail
That definitely is one not-wrong conclusion.
I hope a pragmatic framework like SvelteKit, Astro or TanStack replace NextJS complexity vendors soon.
Indeed. Would you consider https://mastrojs.github.io a "pragmatic framework"?
React router is ... an option. but tanstack is a the most promising one to change the status quo.
With the rolldown update coming with vite 8, It is just a matter of time before next. js is forced to fix its issues
Absolute adoration for how this was published, broken down, and discussed. It really improves my trust in the workers team at Cloudflare.
This is why we need competition and independent benchmarks.
This shames poor performing product/service into action.
Only if they care...
We already have independent benchmarks.
Good job on taking the L gracefully and doing something constructive about it
Speaking of `JSON` functions that can have drastic performance differences, V8 blog[0] recently had a post about improving `JSON.stringify` performance when you don't pass a `replacer` function. Some of the most used functions with performance pitfalls that are easy to trip into.
0: https://v8.dev/blog/json-stringify
Reading this really makes me wonder how does Chrome actually optimize for the plethora of devices running v8 (under Chrome). Definitely involves tricky decisions to be taken for great performance.
nextjs being 4 times slower latency wise than plain react or even vanilla js is pretty funny
The benchmark cases are not comparable to each other. Each does totally different work. They are only meant to compare hosting providers.
Correction: The author of the SvelteKit benchmark says it is designed to do the same work as the Next.js one: https://x.com/bmdavis419/status/1978242304432325041
But the "vanilla" benchmark generates some 3x as much HTML and the react one generates half, so they aren't comparable.
Keep in mind that Theo said the Vanilla benchmark was running too fast so he made it "way way slower" so 4x is not representative of a direct comparison
https://youtube.com/clip/UgkxvcydgHKf-76rZasr0ykMZZol57apKp9...
nextjs is spring of the web, it optimizes productivity rather than app speed.
and whether you are more productive with it or not is completely up to you.
I loved this! Good writeup and very mature response to lots of criticism they took online prior.
Well played Cloudflare.
[dead]
cf has to hire people with obsession not benchwarmers that only activate when someone yells at them because of a twitter argument. there i said it.
vercel only exists because cf got lazy. huge fan of CF, and if cloudflare had the attention to details that vercel has, there would be no vercel. fullstop.
CFs docs, repos, video content but also code samples, sdks (lol all the mcp stuff) usually is subpar to vercel's.
its really annoying that nextjs has to be forked and/or patched to work on cloudflare.
CF isn't lazy at all. Their docs often aren't that great but it's because they seem to be prioritizing launching new products and features
Overall I'm quite positive towards core Cloudflare products like Tunnels, Workers, R2, KV etc, but a lot of newer products are often either thoroughly broken (e.g. Cloudflare AI) or unusable due to insufficient documentation (e.g. Email Routing).
After being burned a few times, I think I'm going to ignore any new Cloudflare product for 12 months after stable release. If their products worked as advertised, I'd be willing to pay considerably more. I think their commitment to the free tier is hamstringing them a little bit.
Yeah I just use Workers and Durable Objects. Stuff like Queues built on DO is better to just use DO
I also got burned and yes I also feel this way about it, i.e. AutoRAG has huge issues too, not to mention the whole MCP/Agents suite of SDKs...
Grab the popcorn, the Vercel v Cloudflare drama unfolds