如何通过 CompressionStream 异步压缩并传输海量原始 DOM 状态快照

“纵有疾风来，人生不言弃”，这句话送给正在学习文章的朋友们，也希望在阅读本文《如何通过 CompressionStream 异步压缩并传输海量原始 DOM 状态快照》后，能够真的帮助到大家。我也会在后续的文章中，陆续更新文章相关的技术文章，有好的建议欢迎大家在评论留言，非常感谢！

CompressionStream 不能直接压缩 DOM 状态快照，需先采集（如 outerHTML、scroll、input 值等）、再序列化为 JSON 并转为 Uint8Array 流，最后通过 CompressionStream 压缩传输，服务端须支持 gzip 解压且正确设置 Content-Encoding 和 Content-Type。

CompressionStream 本身不适用于直接压缩 DOM 状态快照，它是一个用于压缩 ReadableStream 数据流（如 fetch() 响应体、文件读取流）的底层 Web API，不能处理 DOM 树、JavaScript 对象或内存中的状态结构。所谓“原始 DOM 状态快照”，本质是运行时内存中的一组可序列化对象（如 document.documentElement.outerHTML、window.getComputedStyle() 结果、事件监听器元信息等），需先采集 → 序列化 → 编码 → 流式压缩 → 传输，而非对 DOM 节点本身调用 CompressionStream。

下面分三步说明如何合理、高效地完成这一目标：

采集 DOM 快照：轻量、可控、可复现

避免全量 innerHTML 或递归遍历所有节点（易漏样式、伪元素、shadow DOM）。推荐组合方式：

• 使用 document.documentElement.cloneNode(true) 获取结构副本，再移除非必要属性（如 on* 事件、data-* 中的临时 ID）
• 补充关键运行时状态：
  • getComputedStyle(element) 提取计算后样式（仅对可见/关键元素）
  • window.scrollX/Y、document.activeElement?.id、input.value 等交互态字段
• 排除不可序列化内容（如函数、NodeList、Window 引用），用 JSON.stringify() 预检是否可序列化

✅ 示例精简采集逻辑：

const snapshot = {
  html: document.documentElement.outerHTML,
  scroll: { x: window.scrollX, y: window.scrollY },
  activeId: document.activeElement?.id || '',
  inputs: Array.from(document.querySelectorAll('input, textarea, select'))
    .reduce((acc, el) => ({ ...acc, [el.name]: el.value }), {})
};

序列化与流式压缩：用 CompressionStream 真正起效的位置

将采集后的 JS 对象转为字节流，再接入压缩管道：

• 先用 JSON.stringify(snapshot) 得到字符串
• 转为 Uint8Array（UTF-8 编码）：new TextEncoder().encode(str)
• 构造 ReadableStream 并接入 CompressionStream("gzip")
• 直接 .pipeTo() 到 WritableStream（如 fetch() 的请求体）

✅ 完整压缩传输链路：

async function sendCompressedDOMSnapshot() {
  const snapshot = await captureDOMState(); // 上一步封装的采集函数
  const json = JSON.stringify(snapshot);
  const encoder = new TextEncoder();
  const stream = new ReadableStream({
    start(controller) {
      controller.enqueue(encoder.encode(json));
      controller.close();
    }
  });

  const compressedStream = stream.pipeThrough(
    new CompressionStream("gzip")
  );

  await fetch("/api/snapshot", {
    method: "POST",
    body: compressedStream,
    headers: { "Content-Encoding": "gzip" }
  });
}

⚠️ 注意：服务端必须支持解压 Content-Encoding: gzip，且明确声明 Content-Type: application/json。

传输与服务端协同：避免“压缩了但白费”

前端压缩只是半程——若服务端未配置对应解压中间件，请求体将被当作乱码拒绝。关键协同点：

• 请求头必须带 Content-Encoding: gzip（浏览器不会自动加，需手动设置）
• 后端框架需启用 gzip 解析（如 Express + express.raw({ type: 'application/json', limit: '50mb' }) + 自定义解压中间件）
• 若使用 CDN 或网关（如 Nginx、Cloudflare），确认其未在转发前解压并丢弃编码头
• 对超大快照（>10MB），考虑分块压缩（TransformStream 分片）+ 断点续传，而非单次流

? 实测建议：

• 小快照（<1MB）：直接 JSON.stringify + CompressionStream，延迟增益明显（压缩率 60–80%）
• 大快照（>5MB）：先 structuredClone() 深拷贝防冻结，再分批序列化+压缩，避免主线程卡顿
• 避免在 requestIdleCallback 中做压缩——CompressionStream 是异步但非空闲感知，仍可能抢占渲染帧

不复杂但容易忽略：CompressionStream 是流式压缩，不是“一键压缩字符串”。它只工作于 ReadableStream 管道，而 DOM 快照必须先变成流，再进管道。跳过序列化或漏设 Content-Encoding，整个链路就断在第一步。

好了，本文到此结束，带大家了解了《如何通过 CompressionStream 异步压缩并传输海量原始 DOM 状态快照》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！