You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Pre-rendered static pages (e.g., /helloWorld) are being incorrectly served from /cdn-cgi/_cf_seed_data instead of the /assets folder. This causes unnecessary worker invocations and CPU spikes of 200-300ms per page visit.
Fix would require moving the content inside of "/cdn-cgi/_cf_seed_data" to the root of the "/assets" folder. I manually moved a test "test.html" into my assets folder and can confirm that visiting "/test" on my deployed website doesn't hit my worker which is the expectation.
Steps to reproduce
Create default nextjs project for workers.
Deploy
Run tail worker
Expectation is that visiting the static home page should not be hitting your tail worker
Expected behavior
Pages pre-rendered as static should not hit your worker
Static content should be served directly from /assets
@opennextjs/cloudflare version
0.2.1
Node.js version
22.1
Wrangler version
3.88
next info output
Operating System:
Platform: darwin
Arch: arm64
Binaries:
Node: 22.1.0
npm: 10.7.0
Yarn: 1.22.19
pnpm: 8.4.0
Relevant Packages:
next: 14.2.5 // An outdated version detected (latest is 15.0.3), upgrade is highly recommended!
eslint-config-next: 14.2.5
react: 18.3.1
react-dom: 18.3.1
typescript: 5.6.3
Next.js Config:
output: N/A
Additional context
No response
The text was updated successfully, but these errors were encountered:
Played around with opennext, and I was able to fix this on main.
I made a modification to the incremental-cache.ts file and made export const SEED_DATA_DIR = "" and pre-rendered pages no longer hit my worker.
This only works on the main branch, i've noticed that on the experimental middleware branch, it'll still hit my worker (I assume because the middleware is being called).
vicb
changed the title
Worker hit on static assets
Bypass the worker to serve static pages
Nov 22, 2024
Played around with opennext, and I was able to fix this on main.
I would not say "fix" here because:
while the page content is static, I believe you should still apply the middleware and the rewrites/headers in the next config
Setting SEED_DATA_DIR to "" will expose the cache content on public URLs - it's ok for static content but that's probably not something you want for i.e. fetch cache that might include private info/secrets.
Also as you noted the experimental branch is different for now. Cache is now ready there yet.
Once the experimental branch becomes the main branch we can revisit that. It might be possible to determine that a static page would not be affected by the routing (middleware + headers/rewrites) at build time. In such a case we could serve the page without hitting the worker. In other cases we will still need to run the middleware/routing layer.
Note: what OpenNext refers to as "middleware" is actually Next routing + middleware.
Describe the bug
Pre-rendered static pages (e.g., /helloWorld) are being incorrectly served from /cdn-cgi/_cf_seed_data instead of the /assets folder. This causes unnecessary worker invocations and CPU spikes of 200-300ms per page visit.
Fix would require moving the content inside of "/cdn-cgi/_cf_seed_data" to the root of the "/assets" folder. I manually moved a test "test.html" into my assets folder and can confirm that visiting "/test" on my deployed website doesn't hit my worker which is the expectation.
Steps to reproduce
Expected behavior
Pages pre-rendered as static should not hit your worker
Static content should be served directly from /assets
@opennextjs/cloudflare version
0.2.1
Node.js version
22.1
Wrangler version
3.88
next info output
Operating System: Platform: darwin Arch: arm64 Binaries: Node: 22.1.0 npm: 10.7.0 Yarn: 1.22.19 pnpm: 8.4.0 Relevant Packages: next: 14.2.5 // An outdated version detected (latest is 15.0.3), upgrade is highly recommended! eslint-config-next: 14.2.5 react: 18.3.1 react-dom: 18.3.1 typescript: 5.6.3 Next.js Config: output: N/A
Additional context
No response
The text was updated successfully, but these errors were encountered: