Frontier
Performance & cold starts
Performance in Stone.js is mostly structural: the model that keeps your domain portable also keeps it fast. A few deliberate choices, especially around cold starts, are all that is left to you.
#Fast by construction
The Blueprint is built once; each event just runs. Setup cost does not repeat per request.
| Property | Type | Description |
|---|---|---|
| One-time build phase | startup | The manifest is assembled once, not per request; handling an event has no setup tax. |
| Ephemeral container | per event | A fresh, minimal scope per event; nothing long-lived to scan or grow. |
| Agnostic core | always | No platform shims on the hot path; the adapter does the platform work once, at the edge. |
| Sync pipeline path | hot paths | Chains with no async pipe can run synchronously, saving a microtask per step. |
#Cold starts
On serverless and the edge, the cost that matters is the first request after a cold start. The model already minimises it, only the adapter is long-lived, but you can help:
- Keep the bundle lean: fewer, smaller dependencies load faster. Import server-only code behind server loaders so it never enters the client bundle.
- Defer heavy work: open pools and prime caches in an
onStarthook, lazily where possible, not at module top-level. - Prefer the fetch adapter on the edge: the Web-standard path is the lightest on isolate-based runtimes.
- Choose SSG where you can: a pre-rendered page has no server cold start at all; hydrate for interactivity.
#Measure, do not guess
Enable telemetry and watch the spans around real events before optimising. The per-event span tells you where time actually goes; a few meaningful measurements beat intuition, especially across contexts where the cost profile differs.