All questions

What does Croct add to first-load JS? Coming from a 200KB testing snippet

Asked by callie_m on

Ccallie_m

We run a strict first-load budget for clients: 170KB JS, no exceptions. Right now we are stuck with a client-side testing tool whose snippet weighs roughly 200KB even after trimming unused features, and it has to load synchronously or the page flickers. It blows the budget on its own.

Evaluating Croct for a Next.js App Router build. What does it actually add to first-load JS? Docs talk about server-side fetching but I want real numbers before I pitch this to teh client.

Was this helpful?

2 answers

OHOmar Haddad

The honest answer is that for server-personalized pages the number is zero, because the architecture is different, not because the SDK is magically tiny.

With fetchContent in a Server Component, the decision happens on the server and the variant ships as plain HTML. There is no client-side decision engine to download before render, which is exactly where snippet-based tools spend their bytes: they have to ship rules, targeting, and a DOM patcher to the browser and run it before paint.

You only pull in client-side Croct code where you actually need it: the provider plus hooks for client-side tracking or interactive islands that call useContent. Pages that are fully server-personalized add no Croct JS to first load for content.

The server-side vs client-side A/B testing writeup covers why the synchronous-snippet model costs what it costs.

Was this helpful?
Ccallie_m

Zero for server-rendered content is the answer I needed. We track one CTA click client-side, so it sounds like we only pay for the provider on those routes. Thanks.

PKPetra Kovacs

To put a practical shape on it: we audited our own build after migrating. Routes that only use fetchContent showed no change in first-load JS. The routes with the provider and one useCroct call for event tracking gained a modest chunk, nothing near snippet territory, and it loads as part of your normal bundle rather than a render-blocking third-party script. Run next build with the bundle analyzer on a branch and you will have exact numbers for your pitch in half an hour.

Was this helpful?
Still have questions?