SDK performance & overhead

The embeddable widget ships as two bundles. Only the small loader runs on every page load; the heavier capture engine is fetched lazily and only when it is actually needed.

As of the build on September 18, 2026. These sizes are recorded to public/widget-size.json by our widget build and gated in CI, so the numbers on this page track the real bundles rather than a stale claim. The loader target is 30.0 KB gz; the enforced ceiling carries a little headroom so CI blocks regressions, not the current size.

The loader is what loads on every page, and it is deliberately tiny: it contains no rrweb (our build fails if a single rrweb symbol leaks into it). Until a capture actually begins, the loader is close to inert — it paints the reporter button (when your environment gating allows it) and listens for the user to open it.

The capture engine is fetched lazily — only when a report is started, or when capture is turned on for that environment by remote config. It is where rrweb DOM recording and the console/network instrumentation live. So the cost you pay on an ordinary page load is the loader alone; the heavier bundle never downloads unless capture is in play.

Once capture is running, the design keeps its footprint bounded and honest:

• Capture is off by default. Recording does not begin until remote config enables it for the environment and/or the user opens the reporter. A dashboard kill switch and per-environment sampling let you dial exposure down to a fraction of sessions — or to zero — without shipping code.
• DOM recording, not video. We use rrweb to record DOM mutations, not a MediaRecorder screen-capture stream, so there is no video encoder on your users’ CPUs (real-pixel tab video exists only as an opt-in in the Chrome extension, never in the widget or SDKs). Input masking is on by default, and a mutation throttle bounds the work under noisy DOM churn.
• Network bodies are never read. The network instrumentation records request/response metadata (URL, method, status, timing) only. Request and response bodies are hard-nulled — never captured, so there is no serialization cost and no chance of exfiltrating a payload.
• The console buffer is capped. Console arguments are truncated (about 10 KB per argument) and the buffer is bounded (about 500 entries), so a chatty page can’t grow memory without limit.
• Crash isolation. The widget is designed to fail safe: instrumentation is wrapped so an error inside capture degrades the widget, not your application, and never blocks the host page.

Every build runs build:widget, which bundles both files with esbuild, gzips them, and checks two guardrails: (1) rrweb must not leak into the loader, and (2) each bundle must stay under its gzip budget. The same step writes the measured sizes to public/widget-size.json, which this page reads at build time. If a change pushes a bundle over budget, CI fails — so these numbers can’t quietly drift upward between releases.

The same choices that keep the widget light also keep it safe: no video stream from the widget, network bodies never read, inputs masked at the source, and redaction applied in the browser before anything is uploaded. For the full data-handling posture, see our Security page and client-side redaction guide.

Doing a performance or security review? Email security@bugmojo.com and we’ll walk you through the widget architecture and share our latest measurements.