Huge perfomance issues with dev-server

[bhofstaetter]

Hey there, I'm having quite a few problems with the next-js dev server performance. The speed is incredibly slow. It doesn't matter whether you're waiting for HMR, want to call up a page in the frontend or payload backend. Loading times range from 10 to 60 seconds for a single call.

In addition, ram consumption jumps by ~40% as soon as the dev server is started. At the beginning, the server needs ~13GB of ram (I have 32GB in total), and this value increases further over time. Shortly after the server starts, several gb are also stored in the swap memory. The cpu runs at idle speed almost all the time at approx. 3-5% utilization.

The log output looks normal to me (except for the long compile times). Only when I first access the page after starting up I get the following message, the reason for this I have not managed to find yet.

(node:45777) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 unpipe listeners added to [WriteStream]. MaxListeners is 10. Use emitter.setMaxListeners() to increase limit
(node:45777) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 error listeners added to [WriteStream]. MaxListeners is 10. Use emitter.setMaxListeners() to increase limit
(node:45777) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 close listeners added to [WriteStream]. MaxListeners is 10. Use emitter.setMaxListeners() to increase limit
(node:45777) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 finish listeners added to [WriteStream]. MaxListeners is 10. Use emitter.setMaxListeners() to increase limit
(node:45777) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 unpipe listeners added to [WriteStream]. MaxListeners is 10. Use emitter.setMaxListeners() to increase limit
(node:45777) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 error listeners added to [WriteStream]. MaxListeners is 10. Use emitter.setMaxListeners() to increase limit
(node:45777) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 close listeners added to [WriteStream]. MaxListeners is 10. Use emitter.setMaxListeners() to increase limit
(node:45777) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 finish listeners added to [WriteStream]. MaxListeners is 10. Use emitter.setMaxListeners() to increase limit

The difference between webpack and turbopack (which is used) is minimal. devBundleServerPackages: false is also set.
We have around 25 block types, which are stored in the payload config and only referenced in the rest of the system. And around 20 collections. Some of them with versioning enabled.

There are only a few hooks, none of which are particularly complex. The access functions themselves are also not complex.

I would say it's a “standard” multi-tenant payload project. We are using

        "@payloadcms/db-mongodb": "^3.59.1",
        "@payloadcms/email-nodemailer": "^3.59.1",
        "@payloadcms/live-preview-react": "^3.59.1",
        "@payloadcms/next": "^3.59.1",
        "@payloadcms/plugin-multi-tenant": "^3.59.1",
        "@payloadcms/plugin-nested-docs": "^3.59.1",
        "@payloadcms/plugin-seo": "^3.59.1",
        "@payloadcms/richtext-lexical": "^3.59.1",
        "@payloadcms/storage-s3": "^3.59.1",
        "payload": "^3.59.1",
        "next": "^15.5.5",
        "next-intl": "^4.3.12",

Once the project is built (Docker Image), it runs—locally—as fast as you would expect. There is virtually no loading time after each click, and the new content is displayed almost immediately.

Once the Docker image has been deployed in Kubernetes, everything slows down a bit. However, I believe this is due to incorrect resource allocation. What would be your recommendations here, given that approximately 200–300 simultaneous users are expected?

Unfortunately, I'm out of ideas on how to solve the dev-server performance problem. Maybe you can help me? What could be causing these performance issues, and where else could I look?

[matthijs166]

We noticed the same thing! Background jobs started crawling after upgrading to 15.5.4. Rolling back to 15.3.4 instantly fixed the issue. No clue what changed under the hood, but something definitely feels off..

[bhofstaetter]

Wow, downgrading Next makes a difference like night and day. Unfortunately, it only postpones the problem, because after the downgrade my build breaks. Other reasons I could address if necessary, but don't necessarily want to.

Is there a workaround to stay on the latest Next version?

[matthijs166]

It looks like maybe a memory leak? I don't know exact.

Also, possible that this next version is too new for payload and not yet supported?
Cant find that quick info about the recommended next version for the current payload version.

[katelyngrimoldby]

As far as I can tell recommended version is 15.4 according to the templates and this PR. Granted, my experience suggests running 5.5+ isn't the issue.

[katelyngrimoldby]

I'm having the same issue with my own project. No multi-tenent, built from the website template, 14 blocks and 10 combined globals + collections. Compiling anything takes 10-20 seconds and loading a page is 10 seconds minimum (my admin page on startup took 18 seconds!). The dev server (just the website, not even my database) takes 3GB on a 16GB machine, but no impact on CPU. I don't get those same errors, though.

My full dependency list is:

    "@notionhq/client": "^5.6.0",
    "@payloadcms/admin-bar": "3.68.3",
    "@payloadcms/db-sqlite": "3.68.3",
    "@payloadcms/live-preview-react": "3.68.3",
    "@payloadcms/next": "3.68.3",
    "@payloadcms/plugin-form-builder": "3.68.3",
    "@payloadcms/plugin-nested-docs": "3.68.3",
    "@payloadcms/plugin-seo": "3.68.3",
    "@payloadcms/richtext-lexical": "3.68.3",
    "@payloadcms/ui": "3.68.3",
    "class-variance-authority": "^0.7.0",
    "cross-env": "^7.0.3",
    "dotenv": "16.4.7",
    "graphql": "^16.8.2",
    "lucide-react": "^0.562.0",
    "next": "15.4.10",
    "next-sitemap": "^4.2.3",
    "payload": "3.68.3",
    "payload-lucide-picker-next": "^1.6.5",
    "react": "19.2.1",
    "react-dom": "19.2.1",
    "react-hook-form": "7.45.4",
    "sharp": "0.34.2"
  },
  "devDependencies": {
    "@eslint/eslintrc": "^3.2.0",
    "@playwright/test": "1.56.1",
    "@testing-library/react": "16.3.0",
    "@types/escape-html": "^1.0.2",
    "@types/node": "22.5.4",
    "@types/react": "19.2.1",
    "@types/react-dom": "19.2.1",
    "@vitejs/plugin-react": "4.5.2",
    "autoprefixer": "^10.4.19",
    "copyfiles": "^2.4.1",
    "eslint": "^9.16.0",
    "eslint-config-next": "15.4.7",
    "jsdom": "26.1.0",
    "playwright": "1.56.1",
    "playwright-core": "1.56.1",
    "postcss": "^8.4.38",
    "postcss-flexbugs-fixes": "^5.0.2",
    "postcss-nesting": "^13.0.2",
    "postcss-preset-env": "^10.6.0",
    "postcss-relative-opacity": "^0.1.0",
    "prettier": "^3.4.2",
    "typescript": "5.7.3",
    "vite-tsconfig-paths": "5.1.4",
    "vitest": "3.2.3"
  }

[Roman86]

the same problem. Migrated from Next 14 to Next 16 to integrate Payload 3 - the "next server (v16.1.1)" requests processing takes like 1s -> 12s -> 36s -> 47s (according to IDE console output) until completely stuck, CPU (MacBook M4 Pro) 700%, memory fills up to 14+GB. Only dev mode affected, build+start is alright. AI can't help, whatever I try for 2 days, reinitialized many times with several configurations on payload, nextjs, node, typescript and db side. Thank you guys for this thread 🙌, downgrading to 15.4.10 (with next dev --turbo) seems to solve the issue. Can anybody share what happened to NextJS after 15.4? 😭 The plan was using the latest 16 version

[uplg]

NextJS is garbage.. It's just unusable in the recent versions. Takes 104sec to build /admin with an empty payload cms on startup.

[BlvckParrot]

I can confirm, the dev mode is extremely slow using 3.76.1 Payload and Next.js 16.2.0-canary.35, on my macbook pro M1 is almost unusable. Waiting 7+ seconds to see the change even when I only change text in div

[bhofstaetter]

can we get an "official" statement if that's a payload or nextjs related error to get a direction where to investigate?

[odeletech]

4 months no reply... I'm also having the same issue 3.76.1 and Next15. Both PC and Mac

[erikbrgn]

Seeing the same thing. Dev server is incredibly slow. Once it's built in a production-like environment there are no performance issues whatsoever.

In dev it seems it's the rendering portion that takes a lot of time. Compile is always below a second, usually only a few ms while rendering can be upwards of 30 seconds.

[erikbrgn]

I could also add that I've been experimenting with cache components that I know aren't officially supported yet. With cache components enabled I added a "naive" suspense boundary in the (payload) layout, which I thought was the culprit for the slowness, but even with cache components disabled and the suspense boundary removed I get the same render timings.

[BlvckParrot]

I've tried cache components too. But needed to revert back after a while due to various bugs and crashes. But the speed of the dev server was pretty much same (bad).

[bhofstaetter]

bump

[bhofstaetter]

are we the only ones suffering? :D

[erikbrgn]

We discovered on our end that we created a chain of promises in a Payload hook that caused an enormous bottle-neck. Once removed, we went from ~30 seconds per page load to ~1 second in dev 🫡

[mihail-elevenlabs]

@erikbrgn hey, how did you approach debugging in this case? how did you narrow down the issue?

[gtomaka]

We had the same thing. 10 to 60 seconds. For us it wasn't Next.

We profiled the server and almost all the time was in one Payload function,
buildClientFieldSchemaMap.

It builds a map of every field path in a collection. For our config that is
196,295 paths and it takes 82 seconds. A collection with 3 fields takes 1 ms.

The map is cached, but the cache is dropped every time Payload re-initialises.
In dev that is every hot reload. So you pay it again and again.

We have 97 block types. With 25 it would be smaller, but still not free.

The reason looks like this loop in Payload function
packages/ui/src/utilities/buildClientFieldSchemaMap/traverseFields.ts:

for (const [path, subField] of schemaMap.entries()) {
  if (path.startsWith(`${schemaPath

It scans the whole map once for every richText field. So the cost is
(richText fields) x (map size). Both grow with the config.

We patched it locally with a binary search over sorted keys and got 82s down
to 0.25s. The output is the same, we compared all 196,295 entries.

We are on 3.85.1. The 3.x branch has the same code.

Might be worth checking this before rolling back Next.

[bhofstaetter]

That sounds promising :) thank you for sharing! Could you create an PR?

[gtomaka]

Sure. I'll try to share it by the end of the week.

[bhofstaetter]

Hi, did you find the time to submit an PR?

[marcosnc08]

HI!!!! would love to see how you fixed it!

[gtomaka]

Finally wrote this up properly. It's a repo now, so you can run it instead of taking my word for it:

https://github.com/gtomaka/payload-block-perf

pnpm install && pnpm measure times stock against patched in one process. The block library is synthetic and you pick its size, so you can find where your own config sits: 10 blocks → 0.5s, 40 → 8s, 70 → 128s. It's quadratic, which is why it feels fine right up until it doesn't.

Both are still in 3.87.0. The schema map one applies cleanly back to 3.20.0.

Heads up on the second patch! It touches permissions, so please don't apply it blindly. There's a pnpm verify:permissions in there that diffs the raw permission trees for principals that actually get denied. Run it against your own config.

Everything here was only ever run on 3.87.0.

No PR yet but these patch dist, and a real one should go to src on 3.x. Happy to open it if that's the direction you'd want.

Let me know if it helps in your case.

[openscript]

Just tried out Payload CMS for the first time. It ate all my memory and was super slow. The patches from @gtomaka work well. Would it help to open an issue for this? ping @jmikrut