# Does personalization fit inside Oxygen's runtime limits?

Asked by Zhang Wei on 2026-05-27. Tags: shopify, hydrogen, oxygen, performance.

Before committing to anything I want to understand the runtime footprint. We got
burned last year by a vendor SDK that assumed it could spin up its own server
process, which Oxygen simply cannot run, and we only found out during rollout.

Oxygen workers are capped at 128MB and there is no true local runtime for
third-party engines. If Croct resolves content in the loader, what is actually
running inside the worker? Is there a rules engine in memory, and what latency
should I budget for the loader call

## 1 answer

### Answer from fredrik_j (2026-05-27)

Nothing engine-shaped runs in your worker. The SDK makes an API call from the
loader and the decisioning happens on Croct's side, so what you are adding to
the Oxygen worker is essentially a fetch plus a thin client. That is exactly
why this architecture survives on Oxygen while most CRO apps do not: the 128MB
cap and the ban on third-party server processes rule out anything that wants
to evaluate rules or run its own service next to your storefront.

For the latency budget, the documented figure is end-to-end response times
under 90 milliseconds at P95. Treat the loader call like any other awaited
data dependency and set a fallback in the catch so a slow network path never
blocks the render on default content. We have been running this shape in
production for a while and the worker memory profile is indistinguishable
from before we added it.