High performance. Always.

Errorception takes performance seriously. Very seriously.

Worried about performance? Read on to know how Errorception gets out of the way of your site's performance.

  • Asynchronous, deferred loading

    Not only is Errorception's JS code loaded asynchronously, it's loaded after the window.onload has fired. This ensures that not only is Errorception's script non-blocking, it also doesn't contend for bandwidth with your page's resources during the critical page-load process.

    Even so, Errorception starts recording errors right from the very beginning. The script snippet you copy-paste to your site itself starts collecting errors. The externally loaded script later processes this list of errors.

  • Minuscule script size

    Firstly, because of the asynchronous deferred loading mentioned above, Errorception's script file size shouldn't even matter. However, just so you know, the tracking script's size hovers around the 3kb mark. Yes, just 3kb! The size has been kept low by obsessive manual tuning.

  • Global CDN

    Errorception uses Cloudflare's powerful CDN to serve the error tracking code, so that your users always hit the closest of 28 data centers across the world. Cloudflare has nodes all over the Americas, Europe, Asia and Australia.

  • No wrapping of any APIs

    Errorception doesn't wrap any browser APIs at all, nor does it wrap your code at all. All method calls - whether of your code, your libraries, or the browser's APIs - are left untouched. This lets your code run without any interference at all from Errorception.

    Errorception's error tracking is entirely orthogonal to your code, and uses the window.onerror error callback. Some folks have speculated that window.onerror is not good enough, but those speculations are either outdated or simply incorrect. The quality of data collected from window.onerror is at least as good as any other method, and doesn't require any modifications to your code.

  • Minimized processing in the browser

    Errorception does very minimal pre-processing of the error in the browser, preferring instead to do it on our servers. This way, your users' CPU horsepower is used to run your app, not to process errors.

  • Batched upload of errors

    Errorception batches up the errors at the browser for some time before sending it to the server, just in case multiple errors are being raised frequently. This way, your users aren't unnecessarily creating multiple HTTP connections when just one connection can do the job just fine.

  • Super-fast response times

    When an error is posted to Errorception, our servers respond immediately, even before the error has been fully processed. Processing the error is a fairly complex task and can be time-consuming. However, your users aren't kept waiting, and their HTTP connections are responded to as soon as possible.