Significant performance degradation on Payload 3

[immotus]

I followed the migration guide from Payload v2 to v3 for a setup on MongoDB and Cloud Storage (GCP). Most of the migration went really without significant hiccups. However, the performance of the new Next-based Payload is pathetically slow. For example, It takes about seconds 2-3 seconds to switch between Edit mode to Versions, to API.

Look at these times, on a fairly small project.

> cross-env NODE_OPTIONS=--no-deprecation next dev

   ▲ Next.js 15.0.3
   - Local:        http://localhost:3000
   - Environments: .env
   - Experiments (use with caution):
     · turbo

 ✓ Starting...
It looks like you're trying to use TypeScript but do not have the required package(s) installed.
Installing dependencies

If you are not trying to use TypeScript, please remove the tsconfig.json file from your package root (and any TypeScript files in your app and pages directories).


Installing devDependencies (npm):
- @types/react


up to date, audited 795 packages in 3s

167 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities

 ✓ Ready in 5.5s
 ○ Compiling /admin/[[...segments]] ...
 ✓ Compiled /admin/[[...segments]] in 21.2s (4596 modules)
[22:57:50] WARN: No email adapter provided. Email will be written to console. More info at https://payloadcms.com/docs/email/overview.
 GET /admin 307 in 34142ms
 GET /admin 307 in 813ms
 GET /admin/login 200 in 566ms
 ○ Compiling /api/[...slug] ...
 ✓ Compiled /api/[...slug] in 3.3s (4767 modules)
 GET /api/payload-preferences/nav 200 in 6039ms
 GET /api/users/me 200 in 6092ms
 POST /api/users/login 200 in 1911ms
 GET /api/payload-preferences/locale 200 in 505ms
 GET /admin 200 in 781ms
 GET /admin/collections/pages 200 in 1501ms
 POST /admin/collections/pages 200 in 297ms
 POST /admin/collections/pages 200 in 253ms
 POST /admin/collections/pages 200 in 245ms
 GET /admin/collections/pages?limit=10 200 in 1027ms
 GET /admin/collections/pages?limit=10 200 in 1733ms
 GET /admin/collections/pages/66eada6b37de69690684b32d 200 in 2207ms
 GET /api/payload-preferences/collection-pages-66eada6b37de69690684b32d 200 in 510ms
 GET /api/media/662265046f9e2dc53ac5eeb7?depth=0 200 in 17ms
 GET /api/media/662a6f316c2946b69436aa35?depth=0 200 in 18ms
 GET /api/media/66d2ba159ea593f0d43755e7?depth=0 200 in 24ms
 GET /api/media/662a6f316c2946b69436aa35?depth=0 200 in 489ms
 GET /api/media/662265046f9e2dc53ac5eeb7?depth=0 200 in 493ms
 GET /api/media/6622663a9b679b63a755fc2e?depth=0 200 in 496ms
 GET /api/media/6622691462305b5ae2d8b0c8?depth=0 200 in 498ms
 GET /api/media/66d2ba159ea593f0d43755e7?depth=0 200 in 1713ms
 GET /api/media/file/Scarlet%20robin-400x400.webp 200 in 1907ms
 GET /api/media/file/cockatoo-400x400.webp 200 in 1957ms
 GET /api/media/file/Spiral%20Aloe-400x400.webp 200 in 2397ms
 GET /api/media/file/Birds-400x400.webp 200 in 1764ms
 GET /api/media/file/pink-400x400.webp 200 in 4044ms
 GET /admin/collections/pages/66eada6b37de69690684b32d/versions 200 in 3455ms
 GET /admin/collections/pages/66eada6b37de69690684b32d/versions?limit=10 200 in 3442ms

It is about 50-100 times slower than v2.

Just look at the start-up time and the initial load of the /admin route:

GET /admin 307 in 34142ms

User info in 6 seconds?

GET /api/users/me 200 in 6092ms

I conducted the test with the CLI-produced website example on MongoDB, and it is just as slow. Was this whole idea to move to Next.js not worth it?

[andershermansen]

You are running it in dev mode. For best performance you should build it and run it in production mode.

Instead of

pnpm dev

run

pnpm build
pnpm start

Another thing to think about regarding performance is the roundtrip to the database. Where is the code running vs where is the database running. If they are far apart on slow internet, it will go slow. If they are near with fast connection it will be faster.

[immotus]

I'm looking forward to improvements in this space because the performance, especially compared with the previous version, is appalling.

[andershermansen]

@immotus Out of curiosity. Are you using mongodb or postgres? How are you hosting the database?
And how are you hosting payload itself?

[immotus]

@immotus Out of curiosity. Are you using mongodb or postgres? How are you hosting the database? And how are you hosting payload itself?

The working version of Payload 2 is hosted in a GCP Cloud Run express app with GCP-hosted MongoDB. With Payload 3, I'm still struggling with the migration, so it is all local.

[andershermansen]

Ok, so with both database and code local the latency should not be an issue. Also serverless is not an issue.

Are you running with in dev mode pnpm dev or in production mode pnpm build && pnpm start ?
Also, do you have complex/big collection definitions? Some of the optimizations I see in progress will have big effects on large definitions.

[immotus]

It is a production build with a very simple definition of a Global. Same as on v2.

[immotus]

@jmikrut is there any sensible explanation why a simple Global retrieval in Payload 3 (local production build with a local MongoDB) works three times slower (~1000 ms) than in Payload 2 deployed in the Cloud with a remote MongoDB (~180-200 ms). With all/most other things being equal, it appears to me that Next.js is just so much slower than the old way Payload was run.