[HN Gopher] Unpacking Cloudflare Workers CPU Performance Benchmarks
___________________________________________________________________
Unpacking Cloudflare Workers CPU Performance Benchmarks
Author : makepanic
Score : 300 points
Date : 2025-10-14 20:17 UTC (1 days ago)
(HTM) web link (blog.cloudflare.com)
(TXT) w3m dump (blog.cloudflare.com)
| PranaFlux wrote:
| Grab the popcorn, the Vercel v Cloudflare drama unfolds
| horseradish7k wrote:
| competition is how customers get better products
| syrusakbary wrote:
| 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
| skeptrune wrote:
| I loved this! Good writeup and very mature response to lots of
| criticism they took online prior.
| synunlimited wrote:
| 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
| nisten wrote:
| nextjs being 4 times slower latency wise than plain react or even
| vanilla js is pretty funny
| kentonv wrote:
| The benchmark cases are not comparable to each other. Each does
| totally different work. They are only meant to compare hosting
| providers.
| kentonv wrote:
| 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.
| auxiliarymoose wrote:
| 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...
| zeroq wrote:
| 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.
| bradleyg_ wrote:
| Well played Cloudflare.
| orliesaurus wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Yeah I just use Workers and Durable Objects. Stuff like
| Queues built on DO is better to just use DO
| kordlessagain wrote:
| Right. Cloudflare is an authorized man in the middle attack.
| jokethrowaway wrote:
| 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.
| Havoc wrote:
| Good job on taking the L gracefully and doing something
| constructive about it
| pyrolistical wrote:
| This is why we need competition and independent benchmarks.
|
| This shames poor performing product/service into action.
| alhirzel wrote:
| Only if they care...
| aiisthefiture wrote:
| We already have independent benchmarks.
| hu3 wrote:
| My take from this article is that SvelteKit is crazy fast and
| Next.js is a snail
| eastdakota wrote:
| That definitely is one not-wrong conclusion.
| FlyingSnake wrote:
| I hope a pragmatic framework like SvelteKit, Astro or TanStack
| replace NextJS complexity vendors soon.
| rk06 wrote:
| 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
| mb2100 wrote:
| Indeed. Would you consider https://mastrojs.github.io a
| "pragmatic framework"?
| zeroq wrote:
| This is great PR. Well done to whoever orchestrated that post.
| kentonv wrote:
| Thanks! This was 100% produced and orchestrated by engineers on
| the Workers team (including me).
| zeroq wrote:
| 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 wrote:
| 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 wrote:
| Is there any secret beyond what I'm guessing is "hire the
| right people and then _trust_ them"?
| mpeg wrote:
| 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.
| cendyne wrote:
| Absolute adoration for how this was published, broken down, and
| discussed. It really improves my trust in the workers team at
| Cloudflare.
| boarush wrote:
| 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.
| l5870uoo9y wrote:
| 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/
| steelbrain wrote:
| 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 wrote:
| 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.
| pjc50 wrote:
| So a remote, authenticated DB connection over the internet?
| How many db queries per page generation does that generally
| work out as?
| lukecarr wrote:
| 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/
| misiek08 wrote:
| 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 ;)
| aperture147 wrote:
| 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.
| itake wrote:
| Where do you see that "pages seems to be on the way out"? I use
| pages for a few projects...
| aperture147 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| sofixa wrote:
| 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...
| csomar wrote:
| I didn't find it hard to migrate. Pages are workers, so might
| as well just use a worker.
| kelvinjps10 wrote:
| 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
| csomar wrote:
| 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)
| brycewray wrote:
| https://gohugo.io/host-and-deploy/host-on-cloudflare/
|
| https://discourse.gohugo.io/t/hugo-support-in-cloudflare-
| wor...
|
| https://discourse.gohugo.io/t/hosting-a-hugo-site-on-a-
| cloud...
| __jonas wrote:
| 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.
|
| https://developers.cloudflare.com/workers/static-assets/
| csomar wrote:
| 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.
| TiredOfLife wrote:
| 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
| refulgentis wrote:
| 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.
| NicoJuicy wrote:
| 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.
| kentonv wrote:
| > 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:
|
| 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.
| troyvit wrote:
| > and Pages seems to be on the way out, leaving me with Workers
| Assets that are painful to migrate.
|
| 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_...
| kentonv wrote:
| 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.
| yomismoaqui wrote:
| Reminder to use boring tech when building something important
| that should last for some years.
| youngtaff wrote:
| 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).
| jrpelkonen wrote:
| 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 wrote:
| 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.
| jrpelkonen wrote:
| I appreciate the candor, and I agree that auto-adaptation
| probably makes sense in this use case because the workloads
| are unknown and varied.
| noir_lord wrote:
| 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.
| era37 wrote:
| It's pretty crazy how some video by a relatively small content
| creator snowballed into Cloudflare making meaningful changes and
| addressing platform issues
| NicoJuicy wrote:
| And in just under 5 days, that's insanely fast
| kordlessagain wrote:
| I'm sick of seeing Cloudflare marketing on here.
| graycat wrote:
| 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.
| blackhaj7 wrote:
| Kenton is a class act
___________________________________________________________________
(page generated 2025-10-15 23:02 UTC)