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).