How large is the EventDash tracker?

The September 14, 2026 production build measured 10,987 bytes gzip and 9,822 bytes Brotli. The raw minified file was 38,453 bytes. That is the EventDash tracker benchmark. The size check still prints those figures, and it fails the build if gzip goes over 12,288 bytes. Transfer size is the claim. Startup time is not.

Does 11 KB mean the tracker always starts instantly?

No. Transfer size is one input. Browser, device, network, the rest of the page's JavaScript, and the CDN all change startup. EventDash defers optional collectors until idle, and the lite profile skips them. This bundle benchmark does not claim a universal startup time, and it does not claim a Core Web Vitals win.

Can I reproduce the EventDash tracker benchmark?

Yes. From the repo root, run pnpm build:tracker, then pnpm --dir packages/tracker size. The size command reads tracker.min.js and measures raw bytes plus Node gzip and Brotli. It fails when gzip exceeds 12,288 bytes. A future build can move the number. The command is what keeps the copy honest.

What does this benchmark leave out?

Parse time, CDN cache hits, and a page already full of other JavaScript. Those need a browser test against the deployed file. I did not estimate them here. The acceptance checks for startup CPU and mobile Lighthouse are separate, and this post will not stand in for those results.

← Back to Blog

EventDash Tracker Benchmark: 10.73 KB Gzip

Sep 14, 2026•Updated Sep 29, 2026•Wlad

I wanted a number, not the word "small." This EventDash tracker benchmark is that number. On September 14, 2026, the production tracker measured 38,453 bytes raw, 10,987 bytes gzip, and 9,822 bytes Brotli. The size check still prints those figures. I am not rounding them.

The result JSON is public. The build fails above a 12,288-byte gzip ceiling, so a later change cannot quietly blow past the sentence on this page.

Method

I built the same minified file served as tracker.js:

pnpm build:tracker
pnpm --dir packages/tracker size

Rollup writes packages/tracker/dist/tracker.min.js. The size script reads that file and measures raw bytes plus Node's gzip and Brotli, from node:zlib. The run was macOS 25.5.0, Node 24.19.0, pnpm 11.22.0.

Results

Raw minified JavaScript: 38,453 bytes
Gzip: 10,987 bytes (10.73 KB)
Brotli: 9,822 bytes (9.59 KB)
Enforced gzip budget: 12,288 bytes
Budget result: pass

These values are exact for that measured build. A future build can change them. That is why the command fails, instead of a blog sentence that will drift.

What starts immediately

Two phases, not one blob:

Create or restore the anonymous session.
Attach one delegated listener for data-ed-goal.
Queue the initial pageview and session-start event in one cold-start batch.
Start clicks, forms, scrolls, errors, and performance collectors during idle time, when the selected profile enables them.

The lite profile keeps pageviews and delegated goals and skips the optional collectors. The marketing site uses that same-origin profile. The default full profile keeps the existing customer behavior.

Audio fingerprint work is gone. IndexedDB does not open on a successful startup. The offline queue is created only after transport failure.

What this benchmark does not prove

Bundle size is not browser CPU. This run does not claim a universal parse time or a CDN cache-hit time. It also does not claim a Core Web Vitals improvement, or a fast start on a page already full of other JavaScript.

Those need a browser test against the deployed file. Startup CPU and mobile Lighthouse are separate checks. I will not replace them with an estimate.

Reproduce and inspect

Run the two commands above from the repository root. Then inspect:

Free is 100k events/month. Signup if the file size was the question.

Sources

Node's zlib is what gzipSync and brotliCompressSync call in the size script. The measured bytes are in the result JSON.

Key takeaways

The production tracker measured 38,453 bytes raw, 10,987 bytes gzip, and 9,822 bytes Brotli on September 14, 2026.
The size check fails above a 12,288-byte gzip budget.
Pageviews and delegated HTML goals start first. Optional collectors wait for idle time.
This benchmark measures the built file, not CDN latency or startup CPU on a customer site.

FAQ

How large is the EventDash tracker?: The September 14, 2026 production build measured 10,987 bytes gzip and 9,822 bytes Brotli. The raw minified file was 38,453 bytes. That is the EventDash tracker benchmark. The size check still prints those figures, and it fails the build if gzip goes over 12,288 bytes. Transfer size is the claim. Startup time is not.
Does 11 KB mean the tracker always starts instantly?: No. Transfer size is one input. Browser, device, network, the rest of the page's JavaScript, and the CDN all change startup. EventDash defers optional collectors until idle, and the lite profile skips them. This bundle benchmark does not claim a universal startup time, and it does not claim a Core Web Vitals win.
Can I reproduce the EventDash tracker benchmark?: Yes. From the repo root, run pnpm build:tracker, then pnpm --dir packages/tracker size. The size command reads tracker.min.js and measures raw bytes plus Node gzip and Brotli. It fails when gzip exceeds 12,288 bytes. A future build can move the number. The command is what keeps the copy honest.
What does this benchmark leave out?: Parse time, CDN cache hits, and a page already full of other JavaScript. Those need a browser test against the deployed file. I did not estimate them here. The acceptance checks for startup CPU and mobile Lighthouse are separate, and this post will not stand in for those results.