Does personalization fit inside Oxygen's runtime limits?
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
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.