next-on-pages: Failed to publish your Function. Got error: Error: Script startup exceeded CPU time limit.

@nitaking Yeah this is a real issue and something that I believe very often developers can’t do much about (especially if they include third party code which can do things at startup anyways).

We’ve actually already got a solution for this and we should release it soon, but before we can do that some changes need to be made in wrangler and I believe Greg is looking into that.

The solution will be next-on-pages splitting the code appropriately and lazy loading route code so that it is run only when needed resulting in a much lighter startup processing, so from a developer point of view you will hopefully only have to upgrade the next-on-pages package and things should just work 🙂👍

I’m having the same issue right now, i’m not able to update my application because of that.

In my case, the _worker.js file inside .vercel/output/static folder, has 7.2MB, which is very huge for a worker script.

According with : https://developers.cloudflare.com/workers/platform/limits/#worker-startup-time

Script size can impact startup because there’s more code to parse and evaluate.

In my tests, the _worker.js file easily increases a lot the size in every new build with new features, so the script startup will exceed CPU time limit all the time.

For me, this is a deal breaker. I came to the conclusion that cloudflare pages and next.js only works for tiny projects at this moment. Right now, I’m working to get my project out of the cloudflare and considering Vercel, netlify or open-next for deploy to AWS.

If you want a fast solution, probably cloudflare wouldn’t fit 😕

This is extremely encouraging. And extremely is an undestatement. We want to ditch netlify for cloudflare pages but the thing that at some point the app breaks for being too large has been a huge no-no for now, because it’s too scary. Knowing that this issue is being tackled is a thing of pure joy. Paging @danielroe on this, hoping that Nitro will be ready for this change

Eagerly waiting to hear when this is finished, thanks a lot for your time!

Chiming in here - I’m using Remix rather than Next but have the same problems.

is it possible that your index page is doing some (costly?) setup work? could you reduce that?

This is no doubt the issue, but when applications grow complex it’s incredibly hard to pinpoint where that costly setup is coming from. It’s only reproducible when pushing to Cloudflare, so the iteration cycle is slow and there seems to be no way to profile the generated script 😦

@Rigo-m Thanks for the ping. We are in contact now 😊

Since this problem is present in other metaframeworks as well (e.g.: nuxt3 with nitro), would you mind sharing your findings so that it’s possible to pass on these improvements in these other metaframeworks as well?

@Rigo-m thanks a lot for the interest! 😃 and sorry for the late reply 😓 anyways I’ll share the strategy in details when we add it to the project

We’re also planning to contact and try to work with metaframework authors to help in this, although we’ve seen that many metaframeworks will need to change how they bundle the _worker before they can apply such type of strategy (it also depends on how the metaframework itself works and how it splits its code).

Anyways the strategy is simple, basically wrangler is introducing the ability to use dynamic imports, once we have those, instead of bundling everything together (which causes extra code to unnecessarily run) we add dynamic imports so that the code is evaluated and run only when actually used.

In next-on-pages basically the idea is to have a basic worker which simply acts at the next server/router (with just the basic logic, so it’s going to be much faster), then when it needs to use a route, only at that point it dynamically imports that route’s code.

Example

So for example let’s say your app has routeA, routeB and apiRouteX and say routeA uses libA, routeB uses libB and apiRouteX uses libX all of which do some setup work

now we kind of take all of that js code and bundle it together, so all the setup work for libA, libB and libX is always run for every request

with dynamic imports, if you’ll request routeB the worker won’t load the libA and libX code at all, just the libB one with its setup work, so overall every request should be much faster (making it more difficult to hit the startup CPU time limit)

I hope the above helps, as I said I’ll probably make this much more clear and provide a more detailed description of this when we actually add it to the project 🙂 (which should hopefully be pretty soon)

Awesome, thanks for the temporary fix suggestion @bruce-shi 😄

(Anyways hopefully the two PRs will get merged soon 🤞)

Just merged the PR 🙂

@shiyuhang0, @mihazs, @saaymeen, @aufalmarom, @ynishimura, @uglyrobot, @lourou and @olajiredominic (and whoever I might have missed 😅) If you want please try out your apps with the latest beta release: https://www.npmjs.com/package/@cloudflare/next-on-pages/v/0.0.0-b33639f and let me how it goes, hopefully you should not hit the startup time limit anymore 🙂

@zizifn yeah sorry, that’s totally my bad, my change kind of broke this code: https://github.com/cloudflare/next-on-pages/blob/3e2dad8de5f3c10ad7841fda031ca3cc3c98e996/src/buildApplication/buildWorkerFile.ts#L85-L109

(because now there is a bunch of code from Vercel that we don’t process 😓)

so sorry for the inconvenience, I’m on it 🙇

Sharing this experience with a very small project, 5 pages, not many additional dependencies and 2 pages using little data from getServerSideProps.

According to this blog post - the startup time is increasing to 400ms from 200ms:

In the age of AI, WASM, and powerful full-stack applications, we’ve noticed that developers are hitting our current resource limits with increased frequency. We want to be a place where these applications thrive and developers are empowered to build bigger and more sophisticated applications. Therefore, within the next week we’ll be increasing application size limits (JavaScript/WASM bundle size) to 10MB (after gzip) and startup latency limit (script compile time) is being increased from 200ms to 400ms.

Not sure if that’s live or not now.

@zizifn I’m so sorry I extensively looked into this and forgot to reply to you 😓

No, you’re not doing things wrong, we’ve found out that there’s actually currently a runtime bug which sort of causes the AsyncLocalStorage store not to be passed correctly 😓

A colleague of mine has implemented a fix for it: https://github.com/cloudflare/workerd/pull/634 but I am not sure when that will be available in the runtime (maybe this or next week)

I kind of fixed this in my PR with a try-catch hack: https://github.com/cloudflare/next-on-pages/pull/232/files#r1190419297 which basically just prevents the app from breaking but if the ASL store is not present there isn’t much more I can do about it 😓

It is not 100% not good, but as you can see from the apps I mentioned in the PR’s description is sort of holding up decently (and anyways it’ll be fixed as soon as the runtime’s ready)

---

So you can use my pre-release to build and deploy your application and hopefully now it should work nicely

Unfortunately if you try to you won’t be able to run the app locally because of a bug in wrangler pages dev we’re also looking into it and will hopefully get fixed very soon (https://github.com/cloudflare/workers-sdk/pull/3175) 😓

---

PS: I’m so sorry for the inconvenience, one thing after another kept popping up here 😓 (but after I extensively tested my PR’s apps I am confident that it’s all almost sorted out 🙇) (we’ve also been talking about adding proper e2es to the project but haven’t been able to for external reasons, I do really much hope we’ll add some very soon so that moving forward things should never break this badly 😓)

Why isn’t the CPU limit following the bundled/unbounded rules? I.e.: I tried changing to unbounded mode (30s startup time limit vs 50ms CPU Time Limit), but I got the same error after 2 seconds.