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

Asked by callie_m on 2025-11-19. Tags: nextjs, performance, bundle-size.

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.

## 2 answers

### Answer from Omar Haddad (2025-11-19)

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](https://blog.croct.com/post/server-side-vs-client-side-ab-testing)
covers why the synchronous-snippet model costs what it costs.

#### Reply from callie_m (2025-11-20)

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.

### Answer from Petra Kovacs (2025-11-21)

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.