拒绝录屏卡顿与画面瞬移：网页自动滚动录制的底层时钟同步实战
大家在用网页录屏或自动滚动工具时，是不是经常遇到这种情况：明明看着网页滚动得很流畅，但导出的视频却像幻灯片一样卡顿，或者画面经常出现莫名其妙的“瞬移”和跳跃？
这其实不是你的电脑卡了，而是浏览器内部的三个“工人”没有对好表。今天提米哥就用大白话，带大家拆解网页自动滚动录制背后的底层逻辑，看看如何避开这些常见的性能大坑。
为什么你的录屏总是卡顿？因为“三个时钟”没同步
在网页自动滚动录制中，有三个核心环节在同时工作：
– 滚动循环：通过 requestAnimationFrame 控制页面往下滚动的代码。
– 屏幕渲染（Compositor）：浏览器把网页画面画到屏幕上的过程。
– 视频编码器（Encoder）：把屏幕上的画面压缩成视频文件的过程。
问题在于，这三个环节各有各的节奏（时钟）。比如你的显示器是 144Hz，但录制工具并不能完美捕捉到 144 个独立的画面。编码器为了记录真实的画面，通常会生成可变帧率（VFR） 的视频。很多播放器会把这种真实的 VFR 视频误认为是卡顿，但实际上，它比那些为了强行凑帧率而伪造时间戳的视频要准确得多。
如果我们强行让这三个环节共用一个时钟，反而会在错误的层面上做优化，导致录制效果越来越差。
实战避坑指南：停止做这些“帮倒忙”的优化
在开发自动滚动录制工具时，我踩过很多坑，以下是几个最核心的经验教训：
1. 不要强行平滑滚动距离
当页面负载较高时，滚动代码的回调可能会迟到。如果为了弥补这个延迟，让页面一次性滚动一大段距离，画面就会在瞬间“瞬移”。编码器如果刚好捕捉到这个瞬间，视频里就会出现一个生硬的跳跃。
– 正确做法：限制单次滚动的最大距离。宁可让录制速度稍微慢一点，也绝不要在一帧之内让画面跳跃上百像素。同时，保留小数像素（亚像素余数），每次渲染只执行一次 scrollBy，避免在一个回调里连续滚动多次。
2. 不要强行限制录制帧率
为了迎合设置菜单里的“60帧”选项，强行限制 getUserMedia 的捕获帧率是个馊主意。在高刷新率屏幕上，强制的帧率周期无法完美对齐浏览器的渲染节奏，导致录制时漏掉画面，出现“看着 smooth，录出来 stutter”的结构性卡顿。
– 正确做法：取消帧率上限，让录制帧率顺其自然，跟随内容的实际渲染节奏。
3. 不要死磕高分辨率和高帧率
在浏览器本地使用 CPU 进行视频编码（比如通过 WebAssembly 运行 FFmpeg）是非常消耗资源的。当像素吞吐量太高时，编码器会不规则地丢弃画面。
– 正确做法：适当降低分辨率。一个稍微柔和但流畅的画面，远比一个标着“60fps”却卡成 PPT 的视频更容易让人接受。同时，码率必须根据实际的宽高和捕获率来动态调整。
本地编码的内存陷阱
在浏览器里做本地视频转换（比如把 WebM 转成 MP4 或 GIF），本质上是在消耗浏览器的内存。
- GIF 的内存危机：如果直接按全帧率生成 4K 分辨率的 GIF，会瞬间耗尽内存导致崩溃。必须在生成调色板之前，先降低时间分辨率（减少帧数）。
- MP4 的转换超时：在 WebAssembly 里跑完整的 x264 编码非常慢。不要假设“编码总能在 N 秒内完成”，而是要设置一个“无活动看门狗”来检测真正的死锁。
- 诚实的文件后缀：如果容器转换失败，请保留原始的 WebM 或 Matroska 文件，千万不要为了好看，强行把
.webm改名为.mp4自欺欺人。
总结：给开发者的三条忠告
如果你也在开发类似的网页录制或自动滚动工具，请记住这三句话：
– 不要用大跨步去弥补代码的延迟，编码器会把这个谎言公之于众。
– 不要为了 UI 设置好看去强行限制帧率，这会让画面产生严重的锯齿和跳跃。
– 认清本地硬件的极限，当机器带不动时，一个体积较小但诚实的 VFR 文件，胜过一个导致浏览器崩溃的“完美”视频。
本地编码是产品的硬性约束，而不是可以随意绕过的实现细节。展示网页的机器，也就是压缩视频的机器，我们要对它的算力保持敬畏。
