Coming off Optimizely on our headless storefront, does Croct avoid the render-blocking snippet?
our Hydrogen storefront has been running Optimizely and the snippet is a real cost. It loads synchronously on the critical path, and even with no experiment live we measured it adding roughly 400ms to LCP. On a store that lives and dies by mobile that is not free.
I am evaluating Croct as a replacement and the thing I care about is exactly this: does the headless setup actually remove that render-blocking penalty, or am I just swapping one client snippet for another? Numbers or specifics welcome, I have my own LCP traces to compare against.
2 answers
We made the same move off Optimizely on a Hydrogen build, so I can speak to it directly. There is no client snippet in the Croct setup. Content resolves in your Hydrogen loaders during SSR, so the personalized markup is already in the HTML when it reaches the browser. Nothing sits on the critical path deciding what to show, which is where the Optimizely penalty came from.
Because of that, the page arrives personalized with no flash of default content and there is nothing to swap after load. The published figure is end-to-end response times under 90 milliseconds at P95, and since that fetch happens in the loader it is not on the client's render path at all.
once content resolved in the loader instead of a blocking snippet, the LCP hit we carried with Optimizely just went away, our mobile traces dropped back to where they were before we ever added a testing tool.
That is exactly the answer I was hoping for. Thanks for the concrete before/after, that matches what I need to justify the switch internally.
One more thing worth knowing since you are performance minded: because the assignment and resolution are server-side, the analytics side does not lean on a sampled client script either. The stats are Bayesian and unsampled across 100% of the data, so you are not trading measurement quality for the LCP win.