Remove package bloat from V3 beta (slow load times)

[hdodov]

Currently, Payload has a lot of stuff included by default, which results in extremely bad load times. This is what it looks like to compile a blank Next.js page after create-payload-app:

export default async function Page() {
  return <h1>Hello World</h1>
}

 ✓ Starting...
 ✓ Ready in 2.2s
 ○ Compiling / ...
 ✓ Compiled / in 3.6s (514 modules)
 GET / 200 in 3966ms
 ✓ Compiled in 99ms (266 modules)
 GET / 200 in 27ms

It takes 3.6 seconds for the initial load, then 99ms for each change.

If I add a simple getPayload() call to fetch data, this happens:

import config from '@payload-config'
import { getPayload } from 'payload'

export default async function Page() {
  const payload = await getPayload({ config })
  const result = await payload.find({ collection: 'users', limit: 1 })
  const user = result?.docs[0]
  return <h1>Hello {user ? user.email : 'World'}</h1>
}

 ✓ Starting...
 ✓ Ready in 2.8s
 ○ Compiling / ...
 ✓ Compiled / in 13.3s (2711 modules)
 GET / 200 in 14670ms
 ✓ Compiled in 425ms (2461 modules)
 GET / 200 in 320ms

Now it takes 13.3 seconds for the initial load, then 425ms for each change.

Basically, simply fetching data from Payload results in 2.7 times slower load time.

But if we move over to the admin, things get even worse:

 ✓ Ready in 2.7s
 ○ Compiling /admin/[[...segments]] ...
 ✓ Compiled /admin/[[...segments]] in 24.2s (4781 modules)
 GET /admin/collections/media/create 200 in 27663ms
 ✓ Compiled in 769ms (3937 modules)
 GET /admin/collections/media/create 200 in 392ms

Now you have to stare 24.2 seconds at a blank screen, then 769ms on each update (in this example, I'm adding another field to the default Media collection).

---

I understand that this impacts only local dev, but that's my main concern — it's really not a good DX. Sure, it's not that bad, but once you start adding other packages (you know... for your actual site), the load times can really spiral out of control. In my book, over 10 seconds load for a "Hello World" is crazy. Almost 30 seconds for the default create-payload-app is even crazier.

Proposed Solution

Some of the functionality can be added separately as plugins. For example:

• We will never ever use GraphQL in our site. We just don't have a use case for it. Yet, Payload comes built-in with a GraphQL playground that I will never visit, yet wait to compile every single time I launch my project.
• We will never ever use a code field as well. We just don't have a use case for an entire VS Code editor in our CMS either... Yet, Payload comes with the monaco-editor built in.

I haven't measured the actual impact of loading those dependencies, but in our project, they're just dead weight. And I bet that compiling the Monaco editor doesn't come cheap.

In conclusion, jumping from 514 modules to 2711 modules for a simple Hello World page doesn't seem right.

Here's a reproduction repo: https://github.com/hdodov/test-payload/tree/slow-load-times

[ggaidelevicius]

Fully support this.

This is also in line with what jmikrut said with the original 3.0 announcement stream where a big motivation for moving to Next was to heavily cutdown on external dependencies, reduce bundle size, and therefore increase performance.

Would love for the inclusion of gql and other heavier things to be something that is more modular and configurable within payload.config.ts.

[tyteen4a03]

Agree on the code side. For GraphQL, I thought it doesn't get loaded unless you install @payloadcms/graphql?

Also, you're supposed to use getPayloadHMR in Next.js contexts, but I'm not sure if @jmikrut ever came around to fixing the naming.