Files
rrweb/docs/recipes/optimize-storage.md
Justin Halsall bcf93ca926 docs: revamp installation docs for esm and umd (#1788)
* docs: revamp installation docs for esm and umd

Document recommended install paths across the main guides and package
READMEs for rrweb, @rrweb/all, @rrweb/record, @rrweb/replay, and
rrweb-player.

Clarify three usage modes: bundler/npm, browser no-build with
import maps and +esm, and legacy UMD fallback.

* Apply suggestions from code review

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

* Apply formatting changes

* Apply suggestion from @eoghanmurray

Co-authored-by: Eoghan Murray <eoghan@getthere.ie>

* Apply formatting changes

* docs(all): streamline README usage section

Move the guide link next to the import example and remove the
duplicated Usage section to keep docs concise and easier to scan.

* docs(readme): update gzip size badges in zh-cn readme

* docs(plugins): update readme imports to scoped esm packages

Replace `rrweb` default imports and `rrweb.Replayer` usage with
`@rrweb/record` `record` and `@rrweb/replay` `Replayer` in plugin
usage examples.

Also update canvas WebRTC plugin imports to scoped `@rrweb/*`
package names to keep docs aligned with current package structure.

* docs: update docs to prefer scoped esm packages

replace `rrweb` default import examples with `@rrweb/record` and
`@rrweb/replay` across recipes and guides in en/zh-CN.

clarify package selection for new integrations, add `@rrweb/all`
convenience guidance, and refresh CDN/style import snippets for ESM and legacy UMD compatibility.

---------

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Eoghan Murray <eoghan@getthere.ie>
2026-02-17 13:59:02 +01:00

2.9 KiB

Optimize The Storage Size

In some Apps, rrweb may record an unexpected amount of data. This part will help to find a suitable way to optimize the storage.

Currently, we have the following optimize strategies:

  • block some DOM element to reduce the recording area
  • use sampling config to reduce the events
  • use deduplication and compression to reduce storage size

Block DOM element

Some DOM elements may emit lots of events, and some of them may not be the thing user cares about. So you can use the block class to ignore these kinds of elements.

Some common patterns may emit lots of events are:

  • long list
  • complex SVG
  • element with JS controlled animation
  • canvas animations

Sampling

Use the sampling config in the recording can reduce the storage size by dropping some events:

Scenario 1

import { record } from '@rrweb/record';

record({
  emit(event) {},
  sampling: {
    // do not record mouse movement
    mousemove: false
    // do not record mouse interaction
    mouseInteraction: false
    // set the interval of scrolling event
    scroll: 150 // do not emit twice in 150ms
    // set the interval of media interaction event
    media: 800
    // set the timing of record input
    input: 'last' // When input mulitple characters, only record the final input
  }
})

Scenario 2

import { record } from '@rrweb/record';

record({
  emit(event) {},
  sampling: {
    // Configure which kinds of mouse interaction should be recorded
    mouseInteraction: {
      MouseUp: false,
      MouseDown: false,
      Click: false,
      ContextMenu: false,
      DblClick: false,
      Focus: false,
      Blur: false,
      TouchStart: false,
      TouchEnd: false,
    },
  },
});

Compression

Use packFn to compress every event

rrweb provides an fflate-based simple compress function in @rrweb/packer.

You can use it by passing it as the packFn in the recording.

import { pack } from '@rrweb/packer';

record({
  emit(event) {},
  packFn: pack,
});

And you need to pass packer.unpack as the unpackFn in replaying.

import { unpack } from '@rrweb/packer';
import { Replayer } from '@rrweb/replay';

const replayer = new Replayer(events, {
  unpackFn: unpack,
});

Compress the whole session

Use packFn to compress every event may not get the best result.

It's recommended to compress the whole session in the backend, which will have a more efficient compression ratio for some algorithms like deflate.

Deduplication

Another optimizing strategy is deduplication.

Since we need to simulate hover in the replay, rrweb will try its best to inline CSS styles in the events.

So if we are applying rrweb to github.com, we may record many duplicate CSS styles across sessions.

We can iterate the events and extract CSS. Then we can only store one copy of the styles.

This strategy is also possible for the full snapshot across sessions.