Performance

The LogRocket recording script won't slow down your website. We're committed to keeping it that way and to being transparent about what our script does on your pages.

Page Load

LogRocket needs to wrap browser APIs and register event handlers to do its job. This works best when LogRocket is loaded early, before the rest of your page.

To minimize impact on page load, only a small portion of the recording script is ever loaded synchronously: LogRocket.min.js, a compressed, 8 KB script. If you're installing LogRocket using an inline script tag, this script is served by Cloudflare, our CDN, then cached in the browser. If you're installing the logrocket npm package instead, this is the script included in your bundle. It acts as a shim responsible for instrumenting critical browser APIs and asynchronously loading parts of the recording script that are safe to defer until after important resources like stylesheets and images have loaded. In short, we get out of the critical rendering path as soon as possible. This is the same technique used by Google Analytics and similar tools. It means installing LogRocket has a negligible effect on page rendering and time to interactive.

Main Thread Usage

Once LogRocket is loaded, we make sure that our impact on the browser's main thread is minimal. To accomplish this, we offload most processing to a worker thread. We break up any work we're forced to do on the main thread so that we never block it for more than 5 milliseconds. Event handlers added by LogRocket to record browser events like DOM mutations and mouse movements do as little work as possible before returning control to the browser's event loop. In general, all these event handlers do is add events to an in-memory queue from which they're incrementally and asynchronously sent over to the worker thread for processing.

LogRocket is also self-limiting, monitoring its resource usage and using this information to regulate its behavior. Recording quality is automatically reduced or disabled altogether to avoid impacting the performance of the app being recorded. Built-in circuit-breakers prevent runaway resource usage by throttling or stopping capture of certain data types when we notice unusual behavior that would otherwise be expensive to record. This means we can protect against scenarios that could cause degraded performance without necessarily sacrificing the video. For example, if your Redux state grows very large, LogRocket may temporarily stop collecting Redux actions. Or if thousands of messages are suddenly logged to the console every second, LogRocket may temporarily stop collecting console logs at that log level. If these mechanisms kick in during one of your recordings, you'll be notified by special messages in the browser console and the LogRocket recording console that include suggestions for how to avoid them in the future (e.g., sanitize your Redux state).

Bandwidth Usage

LogRocket minimizes its bandwidth usage by encoding all recording data sent over the network as protocol buffers or "protobufs," a binary wire format developed by Google. Protobufs perform better than JSON and other text-based formats. Encoding happens on a worker thread to avoid impacting the main thread, as discussed above.

Exact bandwidth usage varies depending on the application being recorded, largely due to the fact that LogRocket sends an encoded version of the DOM over the network. However, we save a significant amount of bandwidth by not uploading static assets like stylesheets and images. These are downloaded and cached independently by the LogRocket server, then shared across all recordings in which they appear.