Session recording (rrweb) blocks the main thread for several seconds serializing a large DOM

[kelp-ganesh]

Bug description

When session recording is enabled, posthog-recorder.js (rrweb) serializes a large DOM mutation batch / full snapshot synchronously on the main thread, freezing the tab for several seconds. It happens when a large DOM subtree (a data-dense table, ~10k DOM nodes) is rebuilt or re-snapshotted on navigation — the kind of DOM common in data-heavy UIs.

A Chrome Performance profile of the affected interaction shows the recorder dominating the main thread:

• Grouped by 1st/3rd party: posthog.com consumed 22,444.6 ms of main-thread time over a 29.6 s capture (~76% of the profile) while transferring only 0.6 kB — i.e. pure CPU, not network.
• Bottom-up (function level): effectively all heavy self-time resolves to rrweb-record.js, dominated by synchronous DOM traversal during serialization.
• The Frames track shows multi-second frozen frames during the interaction.

Disabling session recording removes the freeze entirely, confirming the recorder is the cause.

We also saw this begin without any change to our application build. The recorder is fetched at runtime from https://us-assets.i.posthog.com/static/posthog-recorder.js, and the ?v= query is cache-busting only (not version pinning), so an unchanged SDK build can start receiving a newer recorder. The served asset's last-modified was recent, which lines up with when the slowdown appeared.

How to reproduce

1. Enable Session Replay for a project.
2. Render a page with a large DOM — e.g. a data table with many node-dense rows (avatars, tag chips, action buttons). Roughly ~50 rows × ~190 nodes/row ≈ ~10k nodes, with realistic per-node attributes/inline styles.
3. Trigger a re-render that rebuilds the table (switch columns/dataset), or navigate so rrweb takes a full re-snapshot.
4. Observe a multi-second main-thread freeze; a Performance profile attributes the time to rrweb-record.js (DOM serialization / parentNode traversal).

Setup

PostHog is initialized once at app start; session recording uses PostHog defaults.

import posthog from "posthog-js";

posthog.init(POSTHOG_PROJECT_KEY, {
  api_host: POSTHOG_HOST, // PostHog Cloud (US)
  loaded: (ph) => ph.identify(userEmail),
});
// No `session_recording` overrides; session replay enabled via project settings.

Related sub-libraries

• All of them
• posthog-js (web)
• posthog-js-lite (web lite)
• posthog-node
• posthog-react-native
• @posthog/react
• @posthog/ai
• @posthog/convex
• @posthog/nextjs-config
• @posthog/nuxt
• @posthog/rollup-plugin
• @posthog/webpack-plugin

Additional context

• Reproduced on the latest posthog-js (1.405.2), and on earlier releases — not specific to a single version.
• attributeFilter reduces attribute-mutation churn but not the structural add/remove batch or the full snapshot.
• This isn't specific to one app's markup: the DOM itself didn't change — the same DOM recorded acceptably before the recorder asset changed, and Session recorder blocks main thread #3273 reports the same freeze in an unrelated app. Large DOMs are normal in data-heavy UIs; the recorder should serialize them without blocking the main thread.
• Screenshots attached: (1) Performance → Summary, 1st/3rd-party grouping; (2) Performance → Bottom-up.

[github-actions]

AI triage for #4217

Conclusion: Valid replay performance bug; not a small/safe fix.
Confidence: 86%
Suggested labels: feature/replay, web

Thanks for the detailed report and profile. The code paths match the described behavior: full snapshots call rrweb's DOM snapshotter synchronously, and large structural mutation batches are walked/serialized synchronously before PostHog's replay buffering/compression code sees the event.

A couple of notes from triage:

• The current browser-side mutation throttler only filters high-frequency attribute mutations after rrweb emits an event; it does not prevent rrweb from traversing/serializing large added subtrees or full snapshots.
• full_snapshot_interval_millis: 0 can reduce periodic full snapshots, but it won't address initial/forced full snapshots or structural add/remove batches.
• blockSelector/ph-no-capture can be used as a mitigation for known very-heavy subtrees, but that is not a general fix.
• If the runtime recorder asset changing independently is a concern, strict_script_versioning: true makes external dependencies load from semver-qualified /static/<sdk-version>/... paths instead of the default unversioned asset path with a ?v= query.

A real fix likely needs rrweb-level work such as chunking/yielding traversal, budgets/backpressure for huge mutation batches/full snapshots, or another replay-safe way to avoid serializing unbounded DOM synchronously.

Investigation

• SessionRecording._lazyLoadAndStart() lazy-loads an external recorder script when rrweb/initSessionRecording are not already present, using a script kind from remote config or defaulting to lazy-recorder.
• external-scripts-loader.ts loads /static/${kind}.js?v=${posthog.version} by default, while strict_script_versioning switches to /static/${posthog.version}/${kind}.js; posthog-core.ts defaults strict_script_versioning to false.
• LazyLoadedSessionRecording._startRecorder() passes allowlisted rrweb options to rrwebRecord(...), then handles emitted events; there is no node-count/time budget before rrweb emits.
• MutationThrottler in packages/browser/src/extensions/replay/external/mutation-throttler.ts only filters attribute mutations by node rate after an rrweb mutation event exists, so it does not reduce rrweb's synchronous work for structural adds/removes or full snapshots.
• packages/rrweb/rrweb/src/record/index.ts implements takeFullSnapshot by locking mutation buffers and calling snapshot(document, ...) synchronously before emitting the full snapshot event.
• packages/rrweb/rrweb-snapshot/src/snapshot.ts recursively iterates dom.childNodes(n) in serializeNodeWithId; it has a max-depth guard but no max-node or time-slicing/yielding guard, so broad DOMs can still be expensive.
• packages/rrweb/rrweb/src/record/mutation.ts handles MutationObserver batches synchronously: processMutations calls genAdds recursively over added subtrees, and emit serializes additions with serializeNodeWithId in the same processing flow.

Relevant files: packages/browser/src/extensions/replay/session-recording.ts, packages/browser/src/extensions/replay/external/lazy-loaded-session-recorder.ts, packages/browser/src/extensions/replay/external/mutation-throttler.ts, packages/browser/src/entrypoints/external-scripts-loader.ts, packages/browser/src/posthog-core.ts, packages/types/src/posthog-config.ts, packages/rrweb/rrweb/src/record/index.ts, packages/rrweb/rrweb/src/record/mutation.ts, packages/rrweb/rrweb-snapshot/src/snapshot.ts

Fix assessment

• Straightforward: no
• Risk: high
• Reason: A small browser-SDK patch would only add mitigations or knobs. The freezing comes from rrweb core snapshot/mutation serialization, where changing traversal scheduling, node budgets, or event semantics risks replay correctness, masking/blocking behavior, iframe/shadow DOM handling, and ingestion compatibility. This needs a targeted rrweb performance design plus regression/performance tests rather than a speculative one-line throttle.

Pi session

The JSONL pi session file(s) for this run were saved to a private gist: https://gist.github.com/marandaneto/3120fa51c840872d49a60af982f51a92

Download one locally, then fork it into your own pi session:

pi --fork path/to/session.jsonl

Saved session files:

• call-1-1-2026-07-22T06-20-47-004Z_019f887b-de1c-7299-a37e-840c4b9227d0.jsonl

Close proposal

None. No issue close action was taken.

---

Generated by posthog-watcher-action using pi.

[ioannisj]

Could be related to this past one? #3273 I checked recent history and I can't see anything that could affect this. @ksvat @TueHaulund mind having a look?

[KarloAldrete]

Reproduced this from a clean build of main — sharing the repro, one finding that I don't think has been reported anywhere, and a concrete proposal with a working prototype. Full write-up: PDF report · harness to reproduce every number: .bench-4217/ on my fork.

Repro (data-dense table like the report describes; compress_events: false, mocked /flags + /ses/, headless Chromium 136 — so these numbers are serialization only, real world is worse):

DOM nodes	rebuild subtree, not recording	start recording (full snapshot)	rebuild while recording
10,415	174 ms	192 ms	331 ms
52,015	415 ms	770 ms	1,611 ms
104,015	767 ms	1,606 ms (one task)	3,260 ms (worst single task 2,408 ms)

Linear in node count, landing in 1–2 long tasks — consistent with the frozen frames in the report. Structural mutation batches cost ~2× a full snapshot of the same tree.

A second stall, separate from the snapshot walk: measuring from startSessionRecording() until the snapshot reaches the wire, there's another main-thread stall of ~641 ms on the 157k-node page — splitBuffer + JSON.stringify of the multi-megabyte snapshot payload before send. Total blocking ≈ 1,723 ms in two tasks, not one.

Root cause framing: the snapshot couples two jobs with very different constraints. Assigning mirror ids must be atomic with the live DOM — but a bare TreeWalker pass over all ~152k nodes is only ~25 ms. Serialization (masking, attributes, string building, allocation) is ~98.5% of the cost and doesn't need the live DOM at all.

Prototype: capture atomically (native getHTML() + one pre-order walk that assigns ids and collects a sidecar of state HTML can't carry: input .value/.checked, CSSOM rules, shadow roots, media state, blocked-element geometry) → hand the string to a Worker that parses it, re-derives the same ids by the same pre-order rules, applies sidecar + masking, and builds + stringifies the rrweb snapshot JSON off-thread.

Head-to-head against main's recorder on the same 157,108-node page (separate cold browser contexts; recorder script preloaded on both sides so absolute ids are comparable):

• main: 1,723 ms blocked (1,082 serialize + 641 payload stringify)
• prototype: 174 ms blocked (getHTML 19 + id-walk&sidecar 145 + postMessage 9), zero long tasks while the Worker runs (parse 167 + build 62 + stringify 67)
• equivalence: 157,108 / 157,108 nodes identical — zero mismatches on type / tag / absolute mirror id / attributes / text / isSVG / isShadow / isShadowHost / isStyle, verified by a recursive structural diff against the wire snapshot. That includes maskAllInputs semantics, ph-no-capture (blocked children get no ids — the 1,000 "secret" test nodes appear in neither payload), CSSOM _cssText, shadow DOM id ordering, SVG flags, media attributes, and textarea value semantics.

Scope notes / honest gaps

• Same-origin iframe content rides the existing iframe-manager attach events (the snapshot's iframe node matched exactly); adoptedStyleSheets stay separate events; canvas capture keeps its existing worker; cross-origin iframes are impossible for any in-page recorder.
• getHTML() needs Chrome/Edge 125+, Firefox 128+, Safari ~18 → capability-detect and fall back to today's synchronous path (worst case = today).
• Strict CSP + workers (CSP violation on Safari due to rrweb worker #3571) → serve the worker from the assets domain like the recorder itself; on failure, fall back.
• Measurement gotchas (longtask observers miss CDP-synchronous work; V8 cache warming between runs; rrweb's global id counter) are documented in the harness.

Proposal — two independent tiers, both opt-in and default-off (mirroring #4226's approach on the player side):

1. Tier 1, conservative: time-sliced sync snapshot behind fullSnapshotYieldBudgetMs (default 0 = byte-identical to today), reusing the existing serializers — bounded slices instead of one long task. Plus a threshold where a giant structural mutation batch emits a checkout full snapshot instead of serializing the giant delta. The three invariants this needs (id reuse from the mirror, unknown-id drops in the mutation buffer, lock/unlock applying buffered mutations against the new mirror) already exist in the vendored rrweb. Happy to open this PR this week.
2. Tier 2: the native+Worker pipeline above, behind remote-config rollout, landing the equivalence-diff suite as a permanent CI gate first. The prototype + harness are the evidence; treating it as RFC material.

(Related prior art: #2585 explored main-thread yielding for SDK loops — never for rrweb serialization; upstream rrweb#1418 proposed offloading snapshot construction to the server, which moves unmasked DOM off-device — this keeps everything in-page.)