Skip to content

[BUG] Performance is unusably slow #653

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
dymoo opened this issue May 8, 2025 · 6 comments
Open

[BUG] Performance is unusably slow #653

dymoo opened this issue May 8, 2025 · 6 comments
Labels
bug Something isn't working needs repro triage

Comments

@dymoo
Copy link

dymoo commented May 8, 2025 •
edited
Loading

Describe the bug

Image

I have all the caching functionality enabled but ttfb still ranges from 1.2s to almost 3 seconds!

Most of my pages are staticky rendered. My landing page reads the 'CF-IPCountry' header to localise pricing to the customers IP address. I don't have any middleware

Image

CPU & wal times vary massively (i'd assume some pages need to be rendered, others can be pulled from cache?)

Unfortunately this makes this library almost completely un usable for almost all websites.

Am I doing something wrong? 3 seconds TTFB will cause customers to stop navigating to the site.

Steps to reproduce

Almost any @opennextjs/cloudflare deployment.

Expected behavior

Pages not to take 1-3 seconds to send first byte.

@opennextjs/cloudflare version

1.0.1

Wrangler version

^4.14.1

next info output

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.4.0: Fri Apr 11 18:33:40 PDT 2025; root:xnu-11417.101.15~117/RELEASE_ARM64_T6031
  Available memory (MB): 49152
  Available CPU cores: 16
Binaries:
  Node: 22.14.0
  npm: 10.9.2
  Yarn: 1.22.22
  pnpm: 9.12.1
Relevant Packages:
  next: 15.3.1 // There is a newer version (15.3.2) available, upgrade recommended! 
  eslint-config-next: 15.2.3
  react: 19.1.0
  react-dom: 19.1.0
  typescript: 5.8.3
Next.js Config:
  output: N/A
 ⚠ There is a newer version (15.3.2) available, upgrade recommended! 
   Please try the latest canary version (`npm install next@canary`) to confirm the issue still exists before creating a new issue.
   Read more - https://nextjs.org/docs/messages/opening-an-issue

Additional context

open-next.config.ts:

import { defineCloudflareConfig } from "@opennextjs/cloudflare";
import doQueue from "@opennextjs/cloudflare/overrides/queue/do-queue";
import kvIncrementalCache from "@opennextjs/cloudflare/overrides/incremental-cache/kv-incremental-cache";

export default defineCloudflareConfig({
  queue: doQueue,
  enableCacheInterception: true,
  incrementalCache: kvIncrementalCache,
});

the https://vercel-commerce-on-workers.web-experiments.workers.dev/ deployment's TTFB seems to range from 500-800ms which is much more reasonable. Is anyone able to link to its repo so I can compare my configs/versions? I can't find it.
@dymoo dymoo added bug Something isn't working triage labels May 8, 2025
@dymoo dymoo changed the title [BUG] Performance is un-usably slow [BUG] Performance is unusably slow May 8, 2025
@jrxcks
Copy link

jrxcks commented May 8, 2025

You know what, This needs to be fixed. This is bad. Hope this helps

@vicb
Copy link
Contributor

vicb commented May 8, 2025

Please attach a repro (link to a GH repository) so that we can take a look.

@dymoo
Copy link
Author

dymoo commented May 9, 2025 •
edited
Loading

Please attach a repro (link to a GH repository) so that we can take a look.

Almost every example I've tested hovers around 1s TTFB.

Image

I also deployed a react router SSR app and I'm hovering comfortably around 150ms TTFB.

Workers KV has terrible read performance, I'm assuming this contributes... Still doesn't explain why CPU time is so high, since i'd assume a KV cache would just be an async request.

Image

@conico974
Copy link
Collaborator

You cannot exactly compare react router with Next. Next does a lot more than just serving a route.

When you request a page on Next.js, it requires loading a full NextServer, which by itself is quite heavy. After that, it needs to fetch the cache entry or render the route in case of SSR.

There's a recent pull request that has been merged, which should significantly reduce CPU times. You can find more details about it here: #656. If you want an explanation #656 (comment)

It's also worth noting that your tests are only measuring a full cold start. Based on the KV graph you shared, it seems that KV didn't even have enough time to replicate to the regional cache.

@dymoo
Copy link
Author

dymoo commented May 9, 2025 •
edited
Loading

You cannot exactly compare react router with Next. Next does a lot more than just serving a route.

When you request a page on Next.js, it requires loading a full NextServer, which by itself is quite heavy. After that, it needs to fetch the cache entry or render the route in case of SSR.

I wanted to compare SSR vs SSR, I understand nextjs is much heavier. I was under the impression that SSR would be a large contributor to the slower performance.

There's a recent pull request that has been merged, which should significantly reduce CPU times. You can find more details about it here: #656. If you want an explanation #656 (comment)

Great, can’t wait. :)

Will nextjs’es adapters functionality improve this as well? It seems a little nuts we have to load a full next app on every request.

It's also worth noting that your tests are only measuring a full cold start. Based on the KV graph you shared, it seems that KV didn't even have enough time to replicate to the regional cache.

I’ve allowed the KV plenty of time (let it overnight) as well as tried to warm it up using a bunch of different requests to different regions. The read performance is still quite disappointing even when everything’s warmed up and replicated.

Thanks for your reply.

@conico974
Copy link
Collaborator

I wanted to compare SSR vs SSR

But even that is not a fair comparison, if you use App router you're comparing RSC SSR vs SSR

Will nextjs’es adapters functionality improve this as well?

In theory it should, but it will depends on how they'll implement it

Regarding KV, you should read this https://developers.cloudflare.com/kv/concepts/how-kv-works/
Pretty sure that what you're seeing is cold read

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working needs repro triage
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@vicb @conico974 @dymoo @jrxcks