Startup performance improvement exploration

[DanRibbens]

I did an exploration around creating a build artifact of Payload for performance and concluded that this is NOT worth pursuing.

Question

Payload sanitizes the user config at runtime on every cold start. In serverless environments (e.g. Lambda) this was hypothesized to hurt startup time. Could we precompute sanitization into a build artifact to cut cold-start cost? A secondary motivation was DX: the runtime representation is inconsistent (payload.collections[slug] is keyed, but globals require payload.globals.config.find(({ slug }) => slug === globalSlug)), and a separate ClientConfig is already built to strip functions for client bundling.

TL;DR

A build artifact is not worth pursuing for performance. Config sanitization is ~10 ms even for large configs — noise next to the real cold-start cost, which is loading the Lexical editor library and its default feature set (~400 ms), code that any richText-using app genuinely needs and that prod already tree-shakes correctly. The DX normalization (keyed global lookups) is worthwhile but stands on its own merits, independent of performance.

Why a full artifact is structurally infeasible anyway

A sanitized config is not serializable. Live functions are interleaved throughout the field tree — access, validate, hooks, filterOptions, defaultValue, admin React components, editor adapters — and are frequently inline/anonymous (access: () => true), so they cannot be emitted as importable references. Configs are also built programmatically (plugins inject collections, fields, and even field types; NODE_ENV branches; loops/spreads), so an artifact computed at build time can silently diverge from the live config at runtime. Sanitization also executes some functions (editor(), richText editor(), jobsCollectionOverrides(), timezone.supportedTimezones()), whose output is non-serializable and must re-run at runtime regardless.

The best a "build artifact" could be is a precomputed data skeleton re-hydrated with live functions at runtime — but re-attaching functions requires walking the live tree, which is the same traversal sanitization already does, plus a drift-detection guard that falls back to full sanitize on mismatch (so all the sanitize code stays).

Measurements

All numbers from this repo (Node 24.15.0). Sanitize/eval runs are medians. Module-load runs are single cold imports; the dev (tsx) numbers include on-the-fly TS transpilation that production does not pay.

Config sanitization scales fine and is cheap

Collections	sanitizeConfig() median (with richText)	(no richText)	richText share
5	0.3 ms	0.2 ms	~31%
25	0.7 ms	0.5 ms	~32%
100	2.7 ms	1.5 ms	~45%
400	10.5 ms	7.0 ms	~33%

Cold (un-JITted) first call at 100 collections: ~11 ms. Even a 400-collection config sanitizes in ~10 ms.

Module load dominates, and it's the editor library

Phase	Cost	Avoidable?
Import richtext-lexical graph (all source, tsx)	~656 ms	Mostly not — see breakdown
Same, with richtext-lexical's 459 files precompiled (swc)	~585 ms	Transpile was only ~70 ms of the total
Default-feature graph only (Lexical core + ~20 features)	~409 ms	No — genuinely used when richText is on
Remaining 29 barrel features (loaded on top)	~48 ms	Yes — prod tree-shakes these out already
lexicalEditor() execution	~5 ms	No
Import payload core (after lexical)	~0 ms	Already loaded as a lexical dependency

Key structural fact: @payloadcms/richtext-lexical sets "sideEffects": ["*.scss","*.css"], so webpack/turbopack tree-shake the 49-feature barrel in a production build. The fat server barrel is therefore largely a dev-mode (tsx, no tree-shaking) tax, not a prod one.

Conclusions

1. Sanitization is negligible (~10 ms). A build artifact would trade real serialization complexity and a silent-drift footgun for ~10 ms on a cold start dominated by hundreds of ms elsewhere. Not worth it.
2. Transpilation (~70 ms) is dev-only. Prod ships precompiled .js; precompiling does not help prod cold start.
3. The barrel/tree-shaking win is ~48 ms and prod already gets it for free via the correct sideEffects flag.
4. The dominant ~400 ms is the default editor + Lexical core, code that any richText-using app genuinely needs.

Recommendations

• Do not build a config artifact for performance. The premise (sanitize is a serverless bottleneck) does not hold, and the function/dynamic-config realities make a complete artifact infeasible regardless.
• Pursue the DX normalization on its own merits. Provide keyed global lookups (e.g. payload.globals[slug]) consistent with payload.collections[slug], so call sites stop doing O(n) .find() scans. This is a non-breaking runtime-shape cleanup, unrelated to startup time.
• Lazy editor loading is the only remaining perf lever, and it's risky. Deferring Lexical until a request actually touches a richText field could dent the ~400 ms, but sanitizeConfig executes editor() eagerly and most richText data operations need it, so the payoff is narrow (only cold starts that never touch richText) and the refactor is non-trivial. Would require its own investigation before committing.

How these numbers were produced

Synthetic configs (N collections × mixed field types incl. group/array/tabs and an optional richText field) timed around sanitizeConfig() with a non-connecting DB stub. Module-load numbers came from timing dynamic import() of the lexical entry (both all-source via tsx and swc-precompiled dist), and from importing the default-feature graph (dist/lexical/config/server/default.js) versus the full barrel to approximate the prod tree-shaking boundary. Benchmark scripts were temporary and removed after measurement.