Does Session Replay Slow Down Your Website?

Session replay adds work to every recorded page, so it is never free; how much it slows down your website depends on your pages, and you should measure it rather than assume. The cost comes from a few specific places: downloading and parsing the script, serialising the page once, observing changes, and uploading events. Knowing which one dominates on your pages tells you what to measure and which lever to pull.

This post walks through each cost centre using AnyReplay's browser and React Native SDKs as the example, then shows how to measure the session replay performance impact on your own site rather than trusting anyone's numbers, including ours.

How big is a session replay script?

Session recording script size varies widely between tools, so ask for the gzipped size of what actually ships to visitors. The AnyReplay browser SDK is about 35 KB gzipped. It wraps the recording half of rrweb, not the player, which only the dashboard needs. CI enforces a 45 KB budget, so a dependency upgrade cannot quietly make it much larger.

How it loads matters as much as its size.

• Script tag. The snippet defines a tiny queueing function and adds the recorder as an async script, so it does not block HTML parsing or rendering. Calls made before it arrives are queued and replayed.
• npm. @anyreplay/browser becomes part of your bundle. Load it with a dynamic import() after the app starts, as the Next.js install guide does, so it stays out of the code needed for the first render.

Either way, parsing and compiling the script still takes main-thread time on the visitor's device. On fast desktops that is hard to notice; on low-end phones it is worth measuring.

The first snapshot

When recording starts on a page, the recorder walks the DOM and serialises every node, attribute and text, including inline stylesheets, into a full snapshot. This is the largest single piece of work the recorder does, and it scales with the size of the DOM. A lean marketing page is cheap; a data grid with thousands of rows, or a page with huge inline SVGs, costs more.

The snapshot is also usually the biggest upload of a session, since everything after it is incremental. If you record a very large page, look at that first request in the network panel to see what you are paying for.

Watching for changes

After the snapshot, the recorder listens with MutationObserver and to input, scroll and pointer events, turning each change into a small event. A mostly static page produces almost nothing. The expensive pages are the very dynamic ones: live tickers, animated counters, charts that redraw constantly, or frameworks that re-render large subtrees on every keystroke. Each mutation is serialised, so a page that rewrites thousands of nodes a second makes the recorder do the same.

Canvas contents are not recorded by the AnyReplay browser SDK, which avoids one of the most expensive kinds of capture.

How much data does session replay use?

It depends on your pages: the size of the first snapshot plus how much changes afterwards. There is no honest single figure. What you can control is how it travels. AnyReplay buffers events and sends them in chunks every 200 events or 5 seconds, whichever comes first, rather than a request per interaction. When the tab closes, the tail is flushed with sendBeacon or a keepalive request. See chunked upload.

To see real numbers for your site, record a typical visit with the network panel open, filter by in.anyreplay.com, and add up the transferred sizes. Repeat on your heaviest page.

Memory

The recorder keeps a map from node ids to DOM nodes so that later events can refer to them, and it buffers events until the next chunk is sent. Memory therefore grows with DOM size and with how quickly events pile up between uploads. Frequent chunking keeps the buffer short. In long-lived single-page apps, check heap snapshots in DevTools after a long session if memory is a concern.

React Native: the snapshot interval

The React Native SDK has no DOM. It reads the committed element tree on a timer, every 500 ms by default, and sends only what changed; an unchanged screen sends nothing. snapshotIntervalMs is the main cost lever: a larger value is cheaper and coarser, a smaller one is smoother and does more work. Values below 100 are rejected. See the React Native SDK reference.

Does session replay affect Core Web Vitals?

It can, and the only reliable answer is to measure your own pages. The most likely place to see an effect is Interaction to Next Paint on pages where the recorder has a lot of work to do at the moment someone interacts, such as a large snapshot or heavy mutation traffic. An async script that does not change layout should not move Largest Contentful Paint or Cumulative Layout Shift much, but verify rather than assume.

How to measure it yourself

In the lab

1. Pick your heaviest real pages, not the home page alone.
2. Run Lighthouse or WebPageTest several times without the snippet and several times with it, using the same device and network throttling. Compare medians, because single runs are noisy.
3. In the Chrome DevTools Performance panel, record a page load and a few interactions with CPU throttling on. Look for long tasks attributed to the recorder script, especially during the first snapshot.
4. Repeat on a mid-range phone or with stronger CPU throttling if many of your visitors use one.

In the field

Lab tests miss real devices and real pages. If you already collect Core Web Vitals from real visitors, use sampling as an experiment: set sampleRate so part of your visitors are recorded, and compare field metrics between recorded and unrecorded visitors. With the npm package, recorder.status() returns recording or sampled-out, which you can attach to your own metrics as a dimension. Because the decision is made once per visitor, each group stays stable across pages. The long tasks API is another field signal to split the same way.

How to reduce the impact

• Record fewer visitors. A sampling rate below 1 means sampled-out visitors take no snapshot and send no requests. See sampling.
• Block heavy regions. Add ar-block to large, fast-changing parts of the page that do not help a reviewer, such as a live ticker or a huge chart. A blocked element's contents are not recorded at all, and replay shows a placeholder of the same size.
• Load later. With the script tag, you can add the recorder script after consent or after the page has settled; queued calls are replayed when it arrives. The trade-off is that nothing before that point is recorded.
• Get CSP right. If your Content Security Policy does not allow connect-src https://in.anyreplay.com (and script-src https://cdn.anyreplay.com for the script tag), uploads fail and the recorder does work it cannot deliver. See Content Security Policy.
• Know what happens offline. The recorder waits instead of hammering: 2 seconds, doubling to a minute, never sooner than a Retry-After asks. It keeps a bounded buffer, then sends the backlog in chunks of about 256 KB. Only a real refusal, such as a paused project, stops it. See circuit breaker.

Does session recording affect page speed?

A small amount, concentrated in script parsing and the first snapshot, and more on very large or very dynamic pages. Measure with and without the snippet on your heaviest pages, compare field metrics between recorded and sampled-out visitors, and use sampling and ar-block where the numbers justify it. rrweb explained covers the recording model in more depth.

Frequently asked questions