[BUG] High CPU usage on releases after 0.5.12

[ankagar]

Describe the bug

After migrating from 0.5.12 to 1.0.0.beta3, I noticed very high cpu usage in my app requests.
It went down when I rolled back to 0.5.12

Metrics view from dashboard

Steps to reproduce

App is very simple, completely SSG with around 20 pages

open-next.config.ts (version 0.5.12) - NEXT_INC_CACHE_KV is not defined (does this disable caching?)

import { defineCloudflareConfig } from '@opennextjs/cloudflare'
import kvIncrementalCache from '@opennextjs/cloudflare/kv-cache'

export default defineCloudflareConfig({
  incrementalCache: kvIncrementalCache,
})

open-next.config.ts (version 1.0.0-beta.3) - no cache binding defined

import { defineCloudflareConfig } from '@opennextjs/cloudflare'
import staticAssetsIncrementalCache from '@opennextjs/cloudflare/overrides/incremental-cache/static-assets-incremental-cache'

export default defineCloudflareConfig({
  incrementalCache: staticAssetsIncrementalCache,
})

PS: I am new to Next.js/Cloudflare but even after reading the docs multiple times, I have not really understood how this cache is really working and what purpose is serving - if anyone can point me to a more verbose write up or video. Thanks!

Expected behavior

CPU is not 20x

@opennextjs/cloudflare version

1.0.0-beta.3

Wrangler version

4.12.0

next info output

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.3.0: Thu Jan  2 20:24:06 PST 2025; root:xnu-11215.81.4~3/RELEASE_ARM64_T8103
  Available memory (MB): 16384
  Available CPU cores: 8
Binaries:
  Node: 22.14.0
  npm: 11.3.0
  Yarn: 1.22.22
  pnpm: N/A
Relevant Packages:
  next: 15.3.1 // Latest available version is detected (15.3.1).
  eslint-config-next: 15.3.1
  react: 19.1.0
  react-dom: 19.1.0
  typescript: 5.8.3
Next.js Config:
  output: N/A

Additional context

No response

[conico974]

Could you provide a reproduction ?
You said that downgrading to 0.5.12 decrease cpu time, have you tested any of the 0.6 ?

[vicb]

See https://nextjs.org/docs/app/deep-dive/caching for some explanation on caching.

Basically caching allow to generate the page once and serve it for a period of time. It should offload your server.

There is nothing we can do without seeing your app code. Please create a minimal repro and add a link to the repository here. Thanks.

[elliotodyl]

I also encountered this problem when upgrading from "0.5.10" to "0.6.6," and I don't know what went wrong.

[vicb]

Again, to make progress on this issue, we need:

• a minimal repro (code in a GH repository + clear instructions)
• know what version caused the perf regression

Without that there is nothing we can do and will close the issue.

Thanks!

[ankagar]

Hi @vicb , I will try to create a minimal repo with issue and get back (will update this post)

Update:

I am able to 'sort of' reproduce it with

npm create cloudflare@latest -- my-next-app --framework=next --platform=workers

Under the red line is with version 1.0.0-beta (actually 0.6.0 shows the same) and above with 0.5.12. The high number is browser making first request, which seems to be very slow (why?) and the subsequent requests are faster. So with 0.6.0 first slow request is 2-3x compared to 0.5.12, subsequent requests are fast with both - which also corresponds to the graphs above P50 being fast but P90+ being slow.

[vicb]

This must be because we dynamically import the server handler in the worker vs a static import before (as suggested by @conico974).

So the time was actually spent before but in the init (i.e. you should see wall time > cpu time in that case).

A few notes:

• we might be able to switch back to top level import now that we do import the routes lazily - but I think it would work only with the most recent versions of next
• there are some limitations on what you can do outside the context of a request in cloudfare (i.e. no IO, timeout, ...)
• process.env needs to reflect the values set in cloudflare and .env files (process.env is populated by workerd after 20250401)

[nxsdev]

私も「0.5.10」から「0.6.6」にアップグレードするときにこの問題に遭遇しましたが、何が悪かったのかわかりません。

I've been on 1.0.0 from the start, so I haven't tried earlier versions, but it seems to have a similar waveform to the others.
It's not a high traffic site (76k requests), but I exceeded the CPU usage time for the $5 Pro plan in half a day.

@elliotodyl
Did your total CPU usage time increase when you updated from “0.5.10” to “0.6.6”?

[elliotodyl]

私も「0.5.10」から「0.6.6」にアップグレードするときにこの問題に遭遇しましたが、何が悪かったのかわかりません。

I've been on 1.0.0 from the start, so I haven't tried earlier versions, but it seems to have a similar waveform to the others. It's not a high traffic site (76k requests), but I exceeded the CPU usage time for the $5 Pro plan in half a day.

@elliotodyl Did your total CPU usage time increase when you updated from “0.5.10” to “0.6.6”?

Yes, my total CPU usage time increased very significantly after updating from 0.5.10 to 0.6.6.

[alexop1000]

I’m seeing similar metrics, and my site isn’t live yet. It’s just from me + one or two others testing.

I’ve not tried with an earlier version, but these stats seem way too high.

[conico974]

Could you try with #656 ?

[alexop1000]

@conico974 Unfortunately, this didn't seem to resolve it for me. My TTFB is still 2-4 seconds on average. Subsequent loads are fine, but the initial page visit takes a long time. (I am still on a workers.dev domain, so doesn't have any cloudflare caching yet beyond what can be defined in the opennext config)

Just to confirm I did it correctly, this is what I replaced my opennext version with:

"@opennextjs/cloudflare": "https://pkg.pr.new/@opennextjs/cloudflare@656"

[conico974]

@alexop1000 It needs to be an ISR/SSG route and you should enableCacheInterception and right now there is an issue that will make it fail with the index page until this is merged opennextjs/opennextjs-aws#860 and integrated in cloudflare.

Just to make one things clear here, there is not much we can do for SSR route. If you have a big route (because of deps or long init time) it needs to be initialized and this will takes time on cold start.