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.
kentonv 18 hours ago [-]
> 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.
There were no changes to the config format in Wrangler 4. The reasons for the major version bump didn't affect 99.99% of users. They are listed here:
Personally I pushed back on bumping the major version at all, because I know even a no-op major version update creates pain. But the team wasn't comfortable given the obscure edge cases. We have resolved, though, that in the future we'll build ways to manage all these issues without requiring a major version bump (e.g. support multiple versions of esbuild, so that you can upgrade wrangler without updating esbuild).
> Pages seems to be on the way out, leaving me with Workers Assets that are painful to migrate.
Pages are not "on the way out". Workers Assets are just a new, more flexible implementation of Pages, which makes it easier to use other Workers features together with Pages. If you don't need those other features, you do not need to migrate. Eventually, we will get to the point where we can auto-migrate everybody, we just aren't there yet.
troyvit 18 hours ago [-]
> and Pages seems to be on the way out, leaving me with Workers Assets that are painful to migrate.
That said I can't actually find a place where CF says pages are deprecated. pages.cloudflare.com seems all-in on it, as does developer.cloudflare.com/pages. I see a reddit post where somebody implies they're deprecating pages, but the page they link to [1] doesn't mention anything about pages going away.
That doesn't take away from the rest of what you're saying, it's just the part that made my heart skip a beat.
It's not deprecated. There's confusion because the implementation is changing to be better-integrated with Workers, and currently it's manual migration to get the new implementation, but eventually it'll be automatic. It'll still be called "Pages" when that happens.
itake 1 days ago [-]
Where do you see that "pages seems to be on the way out"? I use pages for a few projects...
aperture147 1 days ago [-]
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.
pjc50 24 hours ago [-]
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.
rajeevk 22 hours ago [-]
Not the domain registry but CF wants to manage the DNS to make it work. If you do not want them to manage your DNS and want to work by simply pointing your CNAME, they ask you start with their business plan ($250 / per month)
pjc50 20 hours ago [-]
Right, but that's not the same thing and is intrinsic to how CF works - routing DNS requests from different areas to different IPs. Is there any good reason not to just let them serve your DNS if they're serving your website?
(will they accept a delegated subdomain?)
jonathanlydall 19 hours ago [-]
They don't accept delegated subdomains, at least not for .net and .com domains (I haven't tried others).
I don't see how it's "intrinsic to how CF works" that they need to host your DNS records, especially when they don't require it on more expensive plans.
That being said, I don't mind them hosting my DNS records, but it would have been nice if they supported importing zone files from Azure DNS.
csomar 23 hours ago [-]
I didn't find it hard to migrate. Pages are workers, so might as well just use a worker.
kelvinjps10 23 hours ago [-]
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
Generate the files locally and then push them to the worker? Even with a JS based SSG that's the only way to do it and the difference between worker and pages. (workers have no build step)
__jonas 21 hours ago [-]
Just to note because I was confused by this:
I was under the impression that workers are just lambda functions, and therefore would fall under different billing rules than pages which serve static files (with unlimited bandwidth).
But workers apparently have a 'Static Assets' feature that just serves static assets (like pages) and comes with free unlimited requests, unlike worker function invocations, so as you say it seems to be essentially the same as pages.
What I meant the same as worker, is that under the hood, pages are just workers. The Static Assets feature was probably added because the by-request billing wouldn't make any sense for static assets.
sofixa 24 hours ago [-]
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
Reminder to use boring tech when building something important that should last for some years.
TiredOfLife 23 hours ago [-]
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
NicoJuicy 16 hours ago [-]
And nobody on the benchmarks mentioned that Vercel runs it on 2 gb. Instances ( and much more expensive) while Cloudflare is competitive with 128 mb. instances.
I guess that's the difference between building on top of AWS and actually building your own infrastructure.
refulgentis 23 hours ago [-]
Theo knowing what he’s doing died for me when he did a dive into this fancy new data format OpenAI started using to stream responses from the server and how wasteful it is (SSE) (and this was in 2025)
I don’t except everyone to know everything but it made me very careful about differentiating Theo-the-engineer from Theo-the-social-media-dude.
syrusakbary 1 days ago [-]
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
1 days ago [-]
l5870uoo9y 1 days ago [-]
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.
Thanks!
l5870uoo9y 1 days ago [-]
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.
lukecarr 24 hours ago [-]
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!)
So a remote, authenticated DB connection over the internet? How many db queries per page generation does that generally work out as?
misiek08 16 hours ago [-]
C'mon - static pages are like 10ms or less. 200ms is already noticeable, not-instant for humans.
We have 5-10x faster hardware and 10x slower websites ;)
hu3 1 days ago [-]
My take from this article is that SvelteKit is crazy fast and Next.js is a snail
eastdakota 1 days ago [-]
That definitely is one not-wrong conclusion.
FlyingSnake 1 days ago [-]
I hope a pragmatic framework like SvelteKit, Astro or TanStack replace NextJS complexity vendors soon.
rk06 1 days ago [-]
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.
zeroq 1 days ago [-]
This is great PR. Well done to whoever orchestrated that post.
mpeg 21 hours ago [-]
To give a take from a happy cf customer – not only do they have a great engineering culture when it comes to writing blog posts and OSS but also the best customer service of any infra company I've ever used.
The team, including kenton who wrote this post, are often available on discord to provide help and take in feedback about cf products, if you find a bug or have a problem you can often be talking directly to the engineer who looks after that product. I've made PRs and feature suggestions on cloudflare products that got accepted without much hassle / protocol
Don't mean to put down others, but I receive better support from cf on an extremely small monthly bill (the free tier is too good) than I have got from a certain massive company's account managers on six figures a month bills.
kentonv 1 days ago [-]
Thanks! This was 100% produced and orchestrated by engineers on the Workers team (including me).
zeroq 1 days ago [-]
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.
eastdakota 1 days ago [-]
Blog run by the engineering team. I wouldn’t even know how to veto a post if I wanted to. Not in our DNA.
Waterluvian 1 days ago [-]
Is there any secret beyond what I’m guessing is “hire the right people and then trust them”?
era37 20 hours ago [-]
It's pretty crazy how some video by a relatively small content creator snowballed into Cloudflare making meaningful changes and addressing platform issues
NicoJuicy 16 hours ago [-]
And in just under 5 days, that's insanely fast
pyrolistical 1 days ago [-]
This is why we need competition and independent benchmarks.
This shames poor performing product/service into action.
alhirzel 1 days ago [-]
Only if they care...
aiisthefiture 1 days ago [-]
We already have independent benchmarks.
Havoc 1 days ago [-]
Good job on taking the L gracefully and doing something constructive about it
jrpelkonen 21 hours ago [-]
Great write up, focusing on facts without fingerpointing.
But I must admit I was somewhat surprised Cloudflare was not already proactively monitoring and tuning the generation sizes. Configuring the generation sizes was table stakes for JVM performance tuning back in the day.
ErikCorry 21 hours ago [-]
We choose to be transparent when we fix stuff, even if it makes us look a bit silly :-) . We are certainly installing more logging and tracking of this sort of thing!
In general I think the GC should auto-adapt as much as possible. It's a bit of an admission of defeat for the GC author if the users have to spend a lot of time tuning the parameters. What we are doing here is removing the tuning that was no longer correct, and allowing V8 more latitude to pick its own young gen size.
noir_lord 13 hours ago [-]
Not silly at all - with such a massive surface even specialists on a part of it don't see all of their part all of the time :).
Any dev who's been around a while has been bitten by many assumptions or straight blindspots many times.
"Huh..that's weird" has been the entry point to some truly astounding ones over the years for me at least.
jrpelkonen 18 hours ago [-]
I appreciate the candor, and I agree that auto-adaptation probably makes sense in this use case because the workloads are unknown and varied.
nisten 1 days ago [-]
nextjs being 4 times slower latency wise than plain react or even vanilla js is pretty funny
kentonv 1 days ago [-]
The benchmark cases are not comparable to each other. Each does totally different work. They are only meant to compare hosting providers.
But the "vanilla" benchmark generates some 3x as much HTML and the react one generates half, so they aren't comparable.
auxiliarymoose 1 days ago [-]
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
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.
synunlimited 1 days ago [-]
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.
I loved this! Good writeup and very mature response to lots of criticism they took online prior.
boarush 1 days ago [-]
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.
youngtaff 22 hours ago [-]
Nice bit of subtle shade here:
> we chose instead to run our test client directly in AWS's us-east-1 datacenter, invoking Vercel instances running in its iad1 region (which we understand to be in the same building).
blackhaj7 10 hours ago [-]
Kenton is a class act
graycat 13 hours ago [-]
For garbage collection and the idea of assigning storage requests to different categories of (dynamic) storage ....
Apparently part of the algorithm is based on the size of the storage being requested.
Hmm. So, we have historical data of storage requests and for each (i) the size of the request, (ii) how long until the storage is freed, (iii) etc. ....
Guessing about a bizarre case: It might be that on Monday many storage requests of certain small sizes have lifetime just a little longer than the decision to move the request to another category, i.e., the moving effort was inefficient, wasted.
So, in simple terms, for an optimization, for each of the variables have both in the history and real time, make the variable values discrete, altogether may have for some positive integer n a few thousand different n-tuples of variable values; then for each n-tuple pick the best decisions (policies, etc.). Uh, unless this idea has already been tried.
kordlessagain 19 hours ago [-]
I'm sick of seeing Cloudflare marketing on here.
cmdhaus 1 days ago [-]
[dead]
orliesaurus 1 days ago [-]
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.
weird-eye-issue 1 days ago [-]
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
nmfisher 1 days ago [-]
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.
orliesaurus 1 days ago [-]
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...
weird-eye-issue 1 days ago [-]
Yeah I just use Workers and Durable Objects. Stuff like Queues built on DO is better to just use DO
kordlessagain 19 hours ago [-]
Right. Cloudflare is an authorized man in the middle attack.
jokethrowaway 17 hours ago [-]
CF has strong tech core but some products are unusable.
You can see CF Pages had barely zero resources and the product got worse over time.
Lots of issues shipping examples from mainstream frameworks that work flawlessly on vercel, netlify or github pages.
Now they removed support for something and I can't ship half of my "legacy apps". I ship everything on Kubernetes and just cache it with free cloudflare.
It can also be a strategy: they don't care about freeloaders devs shipping another app, they want the enterprise business.
PranaFlux 1 days ago [-]
Grab the popcorn, the Vercel v Cloudflare drama unfolds
There were no changes to the config format in Wrangler 4. The reasons for the major version bump didn't affect 99.99% of users. They are listed here:
https://developers.cloudflare.com/workers/wrangler/migration...
Personally I pushed back on bumping the major version at all, because I know even a no-op major version update creates pain. But the team wasn't comfortable given the obscure edge cases. We have resolved, though, that in the future we'll build ways to manage all these issues without requiring a major version bump (e.g. support multiple versions of esbuild, so that you can upgrade wrangler without updating esbuild).
Incidentally, on the runtime side especially, we're pretty maniacal about backwards compatibility: https://blog.cloudflare.com/backwards-compatibility-in-cloud...
> Pages seems to be on the way out, leaving me with Workers Assets that are painful to migrate.
Pages are not "on the way out". Workers Assets are just a new, more flexible implementation of Pages, which makes it easier to use other Workers features together with Pages. If you don't need those other features, you do not need to migrate. Eventually, we will get to the point where we can auto-migrate everybody, we just aren't there yet.
According to this community post CF isn't going to deprecate pages until workers achieve parity: https://community.cloudflare.com/t/static-web-site-in-worker...
That said I can't actually find a place where CF says pages are deprecated. pages.cloudflare.com seems all-in on it, as does developer.cloudflare.com/pages. I see a reddit post where somebody implies they're deprecating pages, but the page they link to [1] doesn't mention anything about pages going away.
That doesn't take away from the rest of what you're saying, it's just the part that made my heart skip a beat.
[1] https://www.reddit.com/r/webdev/comments/1mme85y/cloudflare_...
(will they accept a delegated subdomain?)
I don't see how it's "intrinsic to how CF works" that they need to host your DNS records, especially when they don't require it on more expensive plans.
That being said, I don't mind them hosting my DNS records, but it would have been nice if they supported importing zone files from Azure DNS.
https://discourse.gohugo.io/t/hugo-support-in-cloudflare-wor...
https://discourse.gohugo.io/t/hosting-a-hugo-site-on-a-cloud...
I was under the impression that workers are just lambda functions, and therefore would fall under different billing rules than pages which serve static files (with unlimited bandwidth).
But workers apparently have a 'Static Assets' feature that just serves static assets (like pages) and comes with free unlimited requests, unlike worker function invocations, so as you say it seems to be essentially the same as pages.
https://developers.cloudflare.com/workers/static-assets/
> 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...
I guess that's the difference between building on top of AWS and actually building your own infrastructure.
I don’t except everyone to know everything but it made me very careful about differentiating Theo-the-engineer from Theo-the-social-media-dude.
That's what everything is about!
PS: It's awesome to see improvements on the OpenNext implementation, that other providers can also reuse
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/
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!
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/
With the rolldown update coming with vite 8, It is just a matter of time before next. js is forced to fix its issues
The team, including kenton who wrote this post, are often available on discord to provide help and take in feedback about cf products, if you find a bug or have a problem you can often be talking directly to the engineer who looks after that product. I've made PRs and feature suggestions on cloudflare products that got accepted without much hassle / protocol
Don't mean to put down others, but I receive better support from cf on an extremely small monthly bill (the free tier is too good) than I have got from a certain massive company's account managers on six figures a month bills.
Again, well played, nice fix, nice writeup.
This shames poor performing product/service into action.
But I must admit I was somewhat surprised Cloudflare was not already proactively monitoring and tuning the generation sizes. Configuring the generation sizes was table stakes for JVM performance tuning back in the day.
In general I think the GC should auto-adapt as much as possible. It's a bit of an admission of defeat for the GC author if the users have to spend a lot of time tuning the parameters. What we are doing here is removing the tuning that was no longer correct, and allowing V8 more latitude to pick its own young gen size.
Any dev who's been around a while has been bitten by many assumptions or straight blindspots many times.
"Huh..that's weird" has been the entry point to some truly astounding ones over the years for me at least.
But the "vanilla" benchmark generates some 3x as much HTML and the react one generates half, so they aren't comparable.
https://youtube.com/clip/UgkxvcydgHKf-76rZasr0ykMZZol57apKp9...
and whether you are more productive with it or not is completely up to you.
0: https://v8.dev/blog/json-stringify
> we chose instead to run our test client directly in AWS's us-east-1 datacenter, invoking Vercel instances running in its iad1 region (which we understand to be in the same building).
Apparently part of the algorithm is based on the size of the storage being requested.
Hmm. So, we have historical data of storage requests and for each (i) the size of the request, (ii) how long until the storage is freed, (iii) etc. ....
Guessing about a bizarre case: It might be that on Monday many storage requests of certain small sizes have lifetime just a little longer than the decision to move the request to another category, i.e., the moving effort was inefficient, wasted.
So, in simple terms, for an optimization, for each of the variables have both in the history and real time, make the variable values discrete, altogether may have for some positive integer n a few thousand different n-tuples of variable values; then for each n-tuple pick the best decisions (policies, etc.). Uh, unless this idea has already been tried.
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.
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.
You can see CF Pages had barely zero resources and the product got worse over time.
Lots of issues shipping examples from mainstream frameworks that work flawlessly on vercel, netlify or github pages. Now they removed support for something and I can't ship half of my "legacy apps". I ship everything on Kubernetes and just cache it with free cloudflare.
It can also be a strategy: they don't care about freeloaders devs shipping another app, they want the enterprise business.