Every page that embedded BugDump used to download 117 KB (gzipped) of JavaScript, whether or not a single visitor ever clicked the report button. Most of that was two libraries almost nobody triggered: the DOM screenshot renderer and the session replay recorder.
They are now fetched on demand.
Before | After | |
|---|---|---|
Downloaded on every page load | 117 KB | 28 KB |
Screenshot library | Always | Only when a DOM screenshot is taken |
Session replay recorder | Always | Only when your plan allows replay |
Nothing was removed. Every feature behaves exactly as it did — the heavy parts just arrive when something needs them.
Two details worth knowing:
Screenshots rarely load the screenshot library at all. The default capture method is screen-capture, which uses a browser API and no library. html2canvas is fetched only on the DOM path, including the automatic fallback when someone denies the screen-capture permission prompt.
Session replay is now gated before the download. Previously the recorder loaded and started on every page, then stopped itself if your plan did not include replay. Now the check happens first, so projects without session replay never download those 82 KB.
Add async to your script tag
The recommended snippet has changed:
<script src="https://bugdump.com/sdk/latest.js" async data-api-key="your-api-key"></script>Without async, the browser pauses page parsing to fetch and run the SDK, and holds DOMContentLoaded until it finishes — so a third-party widget ends up gating your own app's startup. On a throttled connection we measured DOMContentLoaded at 290 ms without the attribute and 58 ms with it.
defer is not a substitute: it frees parsing but still blocks DOMContentLoaded.
Existing installations keep working unchanged — this is a one-attribute improvement, not a requirement.
Manual init no longer needs a load listener
If you initialize the widget yourself (no data-api-key on the tag), the snippet now uses a command queue — the same pattern analytics SDKs use:
<script>
window.bugdump = window.bugdump || function () {
(window.bugdump.q = window.bugdump.q || []).push(arguments);
};
</script>
<script src="https://bugdump.com/sdk/latest.js" async></script>
<script>
bugdump('init', { apiKey: 'your-api-key' });
</script>Calls made before the async script has finished loading are queued and replayed in order once it arrives — no Bugdump is not defined race, and no waiting for the load event (which also waits for every image on the page). The command form covers the whole fire-and-forget API: bugdump('identify', {...}), bugdump('open'), bugdump('setContext', {...}), and so on. The previous load-listener pattern keeps working if you already use it.
If you self-host or proxy the SDK
The SDK is now three files instead of one: latest.js plus bugdump-html2canvas.js and bugdump-replay.js. Copy all three into the same directory. The entry resolves its chunks relative to its own URL, so a copy of latest.js on its own loads fine and looks healthy — but screenshots and session replay break the moment a user tries them.
You may rename the entry file; the chunk filenames must stay as they are. A strict Content-Security-Policy needs your SDK origin in script-src for the chunk requests too.
Nothing to do if you load the SDK from bugdump.com.
npm users
@bugdump/sdk 0.0.32 behaves as before — your bundler still handles the dependencies, and the API is unchanged. The command queue is script-tag only; imports work exactly as they did. The one behavior difference shared by both builds: session replay now starts once the plan check returns rather than immediately at init. The recorder keeps a rolling window, so reports are unaffected.