Why Sentry is 150KB in Next.js (And How We Built a 3.4KB Alternative

When you build a modern application using the Next.js App Router, every kilobyte of client-side JavaScript matters.

Google’s Core Web Vitals—specifically Interaction to Next Paint (INP) and Total Blocking Time (TBT)—are heavily influenced by main-thread execution time during client hydration.

Yet, most production Next.js apps install traditional observability tools (like Sentry or Datadog) without questioning the payload. A standard client SDK often injects 100KB to 150KB+ of minified JavaScript.

Much of that footprint comes from features most web apps don't need: distributed tracing polyfills, complex AST rewriting wrappers, and heavy session replay modules.

Over the past two months, we built SnapTrace to prove that production crash telemetry can fit inside a strict <5KB performance budget.

Today, we published our official v1.0 package to npm: npm i snaptrace.

Here is an architectural breakdown of how we achieved a 3.4KB gzipped footprint with zero main-thread delay.

---

1. Zero Main-Thread Delay via navigator.sendBeacon

Most tracking libraries run heavy HTTP transport logic on the main execution thread. If a user triggers a crash while navigating away, traditional fetch requests can get cancelled or stall the page unmount.

SnapTrace dispatches events asynchronously using the browser's native navigator.sendBeacon:

javascript
var ok = false;
try {
  ok = !!(typeof navigator !== 'undefined' && 
          navigator.sendBeacon && 
          navigator.sendBeacon(url, new Blob([body], { type: 'application/json' })));
} catch (e) {}

if (!ok) {
  fetch(url, { method: 'POST', body: body, keepalive: true }).catch(enqueue);
}