How Much Does Session Replay Slow Down Website Speed?

Does session replay slow down website performance?

Session replay costs a page in three places, which is why the answer to "does session replay slow down website performance" is yes: script bytes at first load, main-thread CPU spent serializing DOM mutations, and upload bandwidth during the visit. How large each cost gets depends on the recorder, the page's DOM size, and the sampling configuration. Sentry publishes a dated benchmark with its methodology attached, and those numbers put the visible cost on the main thread, not on the network.

What are the three costs of recording a session?

A recorder charges a page once at load and then continuously for the rest of the visit. The one-time charge is the bundle, which downloads, parses, and executes before it can take its first DOM snapshot. The continuing charge splits between CPU, which serializes mutation records into JSON events, and network, which uploads those events in batches. Because session replay rebuilds a visit from DOM mutations instead of video frames, the CPU line is the one that scales with your page.

How big is a session replay script?

The recorder bundle is the only part a visitor pays for before the page becomes interactive. Bundlephobia measures @rrweb/record 2.1.4, the recording half of rrweb, at 23,262 bytes gzipped, and the full rrweb package including the player at 78,597 bytes gzipped. Sentry's own documentation states that "as of version 7.78.0 the Session Replay plugin is an additional ~36KB gzipped" on top of its error SDK. Flowsery ships one script under 10 KB. Load whatever recorder you pick asynchronously so its bytes never sit in front of first paint, then run the before-and-after in Lighthouse yourself instead of trusting a size badge.

How much main-thread time does DOM serialization cost?

The CPU cost concentrates in the first full snapshot and then falls to per-batch work for the rest of the session. rrweb registers a MutationObserver, which is why its guide states that rrweb "does not support IE11 and below because it uses the MutationObserver API"; that API hands the recorder a queued batch of records instead of firing once per DOM change, so serialization runs a batch at a time, not on every node touch. Published figures exist for the snapshot: rrweb issue #1337 measured full-snapshot serialization at 34.55 ms average on a document of deeply nested divs, and 27.35 ms after removing repeated closest() lookups.

Google's web.dev article on long tasks defines the threshold and the arithmetic:

blocking time = task duration - 50 ms

A 34.55 ms snapshot therefore contributes 0 ms of blocking time, because "any task that takes longer than 50 milliseconds is a long task" and nothing shorter counts. Snapshots on much larger DOM trees cross that line, and rrweb's tracker has the reports: issue #1547 says an internal check "lags by 1 to 3 seconds on pages with lots of nodes", and issue #1820 documents the main thread blocking when a Zendesk widget is on the page. No public benchmark maps DOM node count to serialization milliseconds, so treat any vendor claim of a fixed per-page CPU figure as unmeasured.

Recorders can push non-urgent work into requestIdleCallback, but the W3C specification caps each idle deadline "to a maximum value of 50ms" so the browser keeps headroom to answer input inside the 100 ms window that feels instantaneous. MDN warns that without a timeout option "it's possible multiple seconds will elapse before the callback is fired", so idle scheduling suits compression and upload, not snapshotting.

How much bandwidth does a session replay upload?

Sentry's benchmark measured network upload for its scenario rising from 3.84 KB with the error SDK alone to 272.51 KB with replay enabled, while download stayed flat at 8.09 MB and 8.07 MB. Upload is the cost your server and your visitor's connection both carry, and it scales linearly with recorded sessions:

monthly replay upload = uploaded bytes per session x sessions per month

At Sentry's measured 272.51 KB per recorded scenario and 50,000 sessions a month, that is 13,625,500 KB, or about 13 GB of upload. Text-heavy apps with slow-changing DOMs land under that figure and canvas or animation-heavy apps land above it, which is why rrweb's storage recipe exists.

Does session replay change Core Web Vitals?

In Sentry's published run, session replay left Largest Contentful Paint and Cumulative Layout Shift alone and moved Total Blocking Time. The benchmark was "last updated on Sept 25, 2023" and ran "on an Apple M1 MacBook Pro against a remote preview server and a remote API backend with 50 iterations".

Total Blocking Time rose by 415.13 ms between the error SDK and the replay build, and Sentry notes that a simpler test page "produced an increase of ~100 ms of total JS blocking time". Layout stability did not move at all, which matches how the metric works: recording reads the DOM and Cumulative Layout Shift scores movement in it. An M1 laptop is not a mid-range Android phone, and nobody has published the same benchmark on low-end mobile hardware, so measure Core Web Vitals from your own field data before deciding the numbers transfer.

How do you cut session replay overhead without losing the replay?

Sampling removes the events that cost the most and prove the least. rrweb's storage recipe recommends mousemove: false to drop mouse movement, scroll: 150 to emit at most one scroll event per 150 ms, media: 800 for media interaction, and input: 'last' to record only the final value of a typed field, on the grounds that sampling "can reduce the storage size by dropping some events". Beyond sampling, blockClass skips whole subtrees, since "an element with the class name .rr-block will not be recorded, instead it will replay as a placeholder", and slimDOMOptions strips DOM parts that carry no replay value. Start with mousemove and scroll on your heaviest page, then re-measure. Masking runs inside the same serialization pass, so how you configure masking changes CPU cost as well as privacy posture.

Frequently asked questions

Does session replay block the first render of a page?

Not when the recorder loads asynchronously, because an async script does not sit in the parser's critical path. What can land near first render is the initial DOM snapshot, which runs after the recorder starts and scales with node count. Sentry's benchmark showed Largest Contentful Paint at 1529.11 ms with replay enabled against 1599.19 ms with no SDK at all, so first paint was not the pressure point in that run.

How much does the recorder script add to page weight?

Bundlephobia lists @rrweb/record 2.1.4 at 23,262 bytes gzipped and the full rrweb bundle at 78,597 bytes gzipped, and Sentry documents its Session Replay plugin at about 36 KB gzipped on top of its error SDK. Flowsery's script is under 10 KB. Check the compressed transfer size in your browser's network panel, since uncompressed figures overstate what a visitor downloads.

Does session replay increase a visitor's data usage?

Yes, on the upload side. Sentry measured 272.51 KB uploaded for its benchmark scenario with replay on, against 3.84 KB with the error SDK alone, while download volume did not move. Visitors on metered mobile connections pay that upload, which is the strongest argument for sampling mousemove out of the stream.

Why does session replay cost more CPU on some pages than others?

Serialization work is a function of DOM node count and mutation rate, not page views. A dashboard that re-renders a large table on every keystroke produces more mutation records than a static article, and rrweb issue #1547 reports lags of 1 to 3 seconds "on pages with lots of nodes". Third-party widgets add to it as well, which is what issue #1820 documents for the Zendesk Web Widget.

Does session replay hurt SEO rankings?

Only through the same path any script does, by moving Core Web Vitals. Google's search documentation says its core ranking systems reward good page experience while warning that Core Web Vitals alone do not guarantee rankings (Google Search Central). Since Sentry's measurement moved Total Blocking Time and left Largest Contentful Paint and Cumulative Layout Shift flat, the metric to watch is main-thread responsiveness.

How do I measure session replay overhead on my own site?

Load your heaviest page with the recorder disabled, record a Chrome DevTools performance profile, then repeat with the recorder enabled and compare scripting time, long task count, and transferred bytes. Run each configuration several times and compare medians, because single runs vary more than the effect you are measuring. Field data from real devices settles what a lab profile only suggests.

Does turning off mousemove tracking save CPU time or just bandwidth?

Both. The post's cost table lists sampling among the controls for main-thread CPU and for upload bandwidth, since every mousemove event the recorder skips is one less mutation record to serialize and one less event to ship. Turning off mousemove with mousemove: false is the same lever recommended first in rrweb's storage recipe.

What counts as a 'long task' that session replay needs to avoid?

Google's web.dev article defines a long task as anything that runs longer than 50 milliseconds on the main thread, with blocking time equal to task duration minus 50 ms. rrweb's full-snapshot benchmark measured 34.55 ms on a document of nested divs, which falls under that line and contributes zero blocking time. Snapshots on much larger DOM trees are the ones that cross it, which is what rrweb's own issue tracker records in reports of multi-second lag.

Can requestIdleCallback stop session replay from blocking the main thread?

Only for work that can wait. Recorders can push compression and upload into requestIdleCallback, but the W3C specification caps each idle deadline at 50 ms, and MDN warns that without a timeout option a callback can sit for multiple seconds before it fires. That makes idle scheduling a fit for background work, not for the initial DOM snapshot that has to run when the recorder starts.

Does session replay cost more on a slow CPU or a slow network connection?

The CPU carries more of the cost in Sentry's published run. Download stayed flat at 8.09 MB versus 8.07 MB with replay on, while Total Blocking Time rose from 2621.67 ms to 3036.80 ms, and the post's own conclusion is that the main thread is where the cost lands, not the network. Upload still grew from 3.84 KB to 272.51 KB, so a metered connection feels it too, just less than a slow CPU does.