Blog |

The Performance Impact of Session Replay Scripts

The Performance Impact of Session Replay Scripts
Table of Contents

Session replay vendors love talking about features and pricing, but rarely publish the technical specs that matter most to developers. We analyzed the actual JavaScript bundles and their performance impacts across five major platforms.

You know what's wild? Bundle sizes range from 36KB to over 550KB gzipped. That's the difference between imperceptible impact and noticeable slowdown for your users.

PostHog

PostHog uses a 52.4KB core library that lazy-loads session replay functionality only when you actually need it.

The open-source architecture is pretty nice too—you can optimize and tree-shake beyond what most vendors offer. Plus, their pricing transparency is refreshing in a space full of "contact sales" buttons.

Bundle size feels manageable, and you get decent React integration with hooks like usePostHog and PostHogProvider. Not groundbreaking, but solid.

Sentry

Sentry's been putting real effort into performance. They managed to compress their session replay bundle down to 36KB through a 35% bundle size reduction initiative.

What I like is their transparency about the technical details. They break down exactly where those kilobytes go: 10KB for compression workers, optional canvas support, and so on. With maximum tree-shaking, you can get down to 29KB, though that requires some configuration work.

Their performance benchmarking shows a 0.24ms FID increase and 373ms Total Blocking Time increase—basically a 14% impact on main thread performance. That's honest reporting you don't always see.

Fullstory

Fullstory sits at 58.8KB gzipped with their "get out of the way" philosophy. They use a small stub that loads the full script asynchronously, which is smart—same strategy Google Analytics uses.

Their approach is more about stability than cutting-edge optimization. The static bundle means no loading surprises, but also no size customization based on what you actually use.

Performance-wise, they claim sub-20ms load times from Google's CDN, which is reasonable. Event handlers run in about 0.037ms according to their documentation.

Pendo

Pendo reports a 54KB bundle size with sub-second guide delivery and data compressed to under 2KB per transmission. They use Amazon CloudFront for distribution, which provides solid infrastructure.

However, Pendo focuses more on user onboarding and product adoption features than pure session replay performance metrics. Their documentation doesn't provide the detailed performance breakdowns you'll find with other vendors.

Contentsquare

Now we get to the heavyweight of the group. At 553.4KB gzipped, Contentsquare is nearly 10x larger than competitors.

Their enterprise compliance features might justify this for heavily regulated industries, but the performance math is unforgiving. Their own documentation admits 25-100ms Total Blocking Time impact on mobile devices—that's entering user-noticeable territory.

The 15-minute browser caching and deferred execution help, but you can't cache away a 550KB JavaScript bundle's initial impact. If you're considering Contentsquare, budget serious time for performance testing.

Quick Performance Comparison Table

Tool Bundle Size (gzipped) Performance Notes
Sentry 36KB (29KB with tree-shaking) 0.24ms FID increase, 373ms TBT increase. Web worker compression prevents main thread blocking
PostHog 52.4KB Lazy-loads session replay functionality. "Near-zero impact" on JavaScript heap through optimized MutationObserver
Pendo 54KB Sub-second guide delivery, <2KB for data transmission. Limited performance documentation available
Fullstory 58.8KB 20ms load time from Google CDN. Event handlers take 0.037ms. Static bundle approach
Contentsquare 553.4KB 25-100ms TBT impact on mobile vs 0-50ms desktop. 15-minute browser caching helps but can't overcome initial impact

The size difference between Sentry (36KB) and Contentsquare (553KB) represents a 15x gap that directly translates to performance impact, especially on mobile devices.

What Independent Testing Shows

Independent benchmarking from Highlight.io provides the clearest picture of real-world impact. Testing actual React applications (not synthetic benchmarks), they found 20-25% CPU increases during recording sessions.

Here's what that means practically: if your app normally uses 40% CPU during heavy user interactions, expect that to jump to 48-50% with session replay running. For most applications, that's manageable overhead that won't break user experience.

The testing also showed 0.017-0.07 seconds added to interaction times—noticeable in benchmarks, but below the threshold where users typically perceive lag.

Pricing Reflects Technical Priorities

PostHog wins on transparency with clear per-recording costs starting at $0.005, dropping to $0.0015 at volume. Their 5,000 free recordings monthly give you real evaluation capacity.

Sentry follows traditional SaaS with $26-$80 monthly tiers based on usage. Their event-based model aligns costs with actual usage, which makes sense.

The enterprise players (Fullstory, Pendo, Contentsquare) maintain pricing opacity that forces sales conversations. Third-party estimates put them at $10,000-$170,000 annually, which might be worth it for compliance-heavy environments but feels excessive for most teams.

What This Means for Your Team

For most development teams, the performance impact shown in testing represents acceptable trade-offs for debugging capabilities. But if you're already struggling with performance or targeting mobile-heavy audiences, you'll want to be more selective.

The key is testing with your actual application. Performance impact varies significantly based on DOM complexity, user behavior patterns, and implementation quality. Run tests with tools like PageSpeed Insights, WebPageTest, or Lighthouse before and after adding session replay to understand the real impact on your specific use case.

What If You Could Determine What You Record?

Most session replay tools record everything, hoping you'll find something useful later. That's backwards.

Rollbar's new Session Replay tool lets you decide what triggers recording. You can capture sessions when errors occur, based on specific exception types, user paths, or custom triggers you configure. No bandwidth wasted on normal user behavior, no performance overhead from always-on recording.

The replays integrate directly into your view of the error details, right where you're debugging. Join the beta and see session replay that helps you fix things instead of creating more data to sort through.

Related Resources

"Rollbar allows us to go from alerting to impact analysis and resolution in a matter of minutes. Without it we would be flying blind."

Error Monitoring

Start continuously improving your code today.

Get Started Shape