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.
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 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.
Yes, competition is good and mergers and acquisitions are bad. It also shows why you always have to internally be comparing yourself to the competition and not be complacent, before someone independently does the comparison for you and you're embarrassingly caught with your pants down.
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.
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.
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.
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 ;)
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.
> 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.
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.
> 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).
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.
It's pretty crazy how some video by a relatively small content creator snowballed into Cloudflare making meaningful changes and addressing platform issues
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.
30 comments
[ 1377 ms ] story [ 1027 ms ] threadThat's what everything is about!
PS: It's awesome to see improvements on the OpenNext implementation, that other providers can also reuse
0: https://v8.dev/blog/json-stringify
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.
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.
This shames poor performing product/service into action.
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.
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/
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_...
> 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).
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.
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.