File size is way too much

[SaintPepsi]

#43 (comment)

This recording is absolutely massive.

[SaintPepsi]

Findings from analyzing the linked recording

The exported report (openjam-...html, ~87.6 MB) is almost entirely one thing: the #openjam-data script tag (rrweb event stream) contains 44 losslessly-encoded PNG data URIs — the rest of the document (CSS/JS/markup) is only a few KB.

Root cause

src/rrweb-recorder.js calls rrweb.record({ inlineImages: true, emit }) with no dataURLOptions, so every <img> on the page (movie posters, banners, seat-map art on this Village Cinemas page) gets redrawn to an offscreen canvas and stored as lossless PNG. On an image-heavy page that's dozens of multi-hundred-KB–multi-MB blobs per session.

This is already a known, flagged gap that never got wired in:

• src/rrweb-recorder.js has a comment directly above the record() call: "Ships default PNG (lossless)... Size knob if reports prove too large (reversible fast-follow): dataURLOptions: { type: "image/jpeg", quality: 0.8 }." — never applied.
• REPLAY_DESIGN.md §4 specs dataURLOptions: { type: 'image/webp', quality: 0.6 } from the start.
• REPLAY_DESIGN.md §6 also specs compressing the whole event stream with fflate/@rrweb/packer before embedding ("50 MB of inline JSON chokes browsers"), but report-builder.js:40 does a raw JSON.stringify(report) with zero compression, and neither fflate nor @rrweb/packer is in package.json.
• The designed sampling throttles and slimDOMOptions (to cut snapshot/mutation noise) also never made it into the actual record() call.

So three size mitigations exist in the design doc and none shipped in the recorder.

Suggested fix, ranked by leverage

1. dataURLOptions: { type: 'image/webp', quality: 0.6 } in src/rrweb-recorder.js's record() call — one line, already called out in-code as the reversible fast-follow. Since the file is ~all inlined images, this is the highest-leverage single change.
2. Compress the event stream on export with @rrweb/packer (fflate), per REPLAY_DESIGN.md §6 — wrap events before embedding in report-builder.js, ship a matching unpack() in the viewer.
3. Add the originally-specced sampling + slimDOMOptions to record() — smaller win, but free and already designed.

Happy to send a PR for #1 (and optionally #2) if useful.