Optimizing ByteDance Frontend Monitoring SDK: Size Reduction, Benchmarking, and Real‑World Performance Analysis

Background – ByteDance’s frontend performance monitoring SDK serves billions of users, so its own performance must be extremely high. As business features grow, the SDK risks bloat from added logic, polyfills, and compatibility code, which can degrade download and execution time.

SDK Size Optimization

Micro‑level – Reduce redundant code, avoid long class names, and prefer functional programming over class‑based OOP to improve minification. Example:

class ClassWithLongName {
    methodWithALongLongName() {}
}

After TypeScript compilation and minification the code remains large because property names cannot be shortened. Rewriting as a function reduces size by over 50%:

function functionWithLongName() {
  return function MethodWithALongLongName() {}
}

Other micro optimizations include passing arrays instead of objects to reduce property name length, and avoiding nullable operators (?., ??, ??=) and heavy syntax that triggers polyfills.

Macro‑level – Split non‑essential logic into async chunks, minimize polyfill usage, and deduplicate constant strings by extracting them into shared variables.

let ADD_EVENT_LISTENER = 'addEventListener';
let LOAD = 'load';
a[ADD_EVENT_LISTENER](LOAD, cb);

These techniques can shrink bundle size by 10‑15% on mobile environments.

Performance Measurement Tools

The most performance‑critical parts of the SDK are initialization listeners, request reporting, and data caching. To measure them, the article uses the benny benchmark library:

const { suite, add, cycle, complete } = require('benny');
// measure SDK collectors setup
suite('collectors setup',
  add('route', () => route(context)),
  add('exception', () => exception(context)),
  // ... other collectors
  cycle(),
  complete()
);

Because the SDK relies on browser APIs, benchmarks are run in a headless Chrome via puppeteer :

const browser = await puppeteer.launch();
const page = await browser.newPage();
await page.exposeFunction('pushResult', result => benchmark.results.push(result));
await page.addScriptTag({ content: file.toString() });
// collect profiling data

Results show that performance observers can add up to 21 ms, and combined listeners for FP, FCP, LCP, CLS exceed 10 ms, becoming a bottleneck.

Real‑World Analysis with Perfsee Lab

Perfsee Lab runs the instrumented page in a headless browser and compares a baseline page (no SDK) with an SDK‑injected page. The comparison reveals that the SDK adds roughly 70 ms to FCP, 90 ms to LCP, and 200 ms to load on mobile, with only one extra request.

Flame‑graph profiling shows that listeners such as onBFCacheRestore consume >15 ms before load, indicating opportunities for optimization.

Problem Analysis & Optimizations

Slice monitoring tasks and schedule low‑priority work with requestIdleCallback .

Share listeners for metrics that watch the same events (e.g., CLS and LCP both listen to onBFCacheRestore ).

Batch network requests via CDN combo or custom combo services, and use navigator.sendBeacon for reliable unload reporting.

After applying these changes, re‑benchmarking shows the SDK’s impact on FCP, LCP, and load is minimal, meeting high‑performance standards.

Further Reading

ByteDance’s monitoring solution is available on Volcano Engine; developers can scan the QR code for a 30‑day free trial and read the original article for more details on Perfsee.