Chrome高刷新率下requestAnimationFrame帧丢失及首帧不显示问题求助

问题现象 #

• 165Hz刷新率显示器上，requestAnimationFrame出现丢帧，60Hz刷新率下无此问题
• 首帧内容未正常显示

问题原因分析 #

1. 首帧不显示的核心原因 #

首次调用RAF回调时，代码直接通过document.body.innerHTML替换了整个body的DOM结构，覆盖了初始的<p>requestAnimationFrame Test</p>。同时浏览器初始渲染流程还未完成，RAF回调的DOM操作打断了首帧渲染，导致初始内容没机会显示出来。

2. 165Hz下丢帧的关键诱因 #

（1）高频DOM重写的性能开销

每一次RAF都完整替换body的innerHTML，这会触发全量重排重绘。165Hz下单帧的时间窗口仅约6ms（1000/165≈6.06ms），而60Hz下单帧窗口有16.67ms。重排重绘的开销在6ms窗口内很容易超出阈值，导致浏览器跳过帧；而16.67ms的窗口足够容纳这些操作，所以60Hz下表现正常。

（2）无意义setTimeout的干扰

代码里的空setTimeout(() => {})会向事件队列添加一个宏任务。虽然回调是空的，但宏任务的存在会抢占后续RAF的执行时机——高刷新率下时间窗口本来就紧，这种额外的事件队列调度很容易导致帧丢失。

（3）Chrome的VSync调度兼容性

Chrome在高刷新率显示器上的RAF调度可能存在精度偏差，当RAF回调执行时间接近或超过单帧时长时，浏览器会跳过下一帧来追赶VSync信号，这种情况在165Hz下更容易触发，因为单帧时间更短。

修复方案 #

• 避免全量DOM替换：提前创建好需要更新的DOM元素，只修改元素的textContent而非重写整个innerHTML，大幅降低重排重绘开销。
• 移除无效代码：删掉空的setTimeout，减少事件队列的不必要调度。
• 压缩回调执行时间：确保RAF回调内的逻辑尽可能轻量化，把计算或DOM操作控制在单帧时间的80%以内（165Hz下控制在5ms左右）。

修复后的示例代码 #

<!doctype html>
<html>
  <head>
    <script>
      let rafPast = 0;
      // 提前创建需要更新的DOM节点
      const diffEl = document.createElement('div');
      const pastEl = document.createElement('div');
      const timeEl = document.createElement('div');
      document.body.append(diffEl, pastEl, timeEl);

      const start = (rafTime) => {
        // 仅更新文本内容，不重写DOM结构
        diffEl.textContent = `${rafTime - rafPast}`;
        pastEl.textContent = `rafPast: ${rafPast}`;
        timeEl.textContent = `rafTime: ${rafTime}`;

        if (rafPast > 1000 && document.body.style.backgroundColor !== "green") {
          console.log(`timestamps {rafPast: ${rafPast}, rafTime: ${rafTime}}`);
          document.body.style.backgroundColor = "green";
        }
        console.log(`global {rafPast: ${rafPast}, rafTime: ${rafTime}}`);
        requestAnimationFrame(start);
        rafPast = rafTime;
      };
      requestAnimationFrame(start);
    </script>
  </head>
  <body>
    <p>requestAnimationFrame Test</p>
  </body>
</html>

内容的提问来源于stack exchange，提问作者MaximPro