在这漫长的 3 秒钟内，浏览器的主线程被完全挂起。它无法响应点击，无法处理滚动，也无法执行其他的 JavaScript 代码。此时我们观察这四个方块的命运，结果令人大跌眼镜。

当 JS 主线程被死循环卡死时奇怪的现象发生了：并不是所有的动画dou停止了。让我们结合代码逐一分析这四个方块的遭遇。

这是唯一的幸存者。它的实现非常简单，仅仅使用了 CSS 的 transform 属性。

/* 仅改变 transform */
@keyframes pure-transform {
  from { transform: rotate; }
  to { transform: rotate; }
}

生还原因：脱离主线程。

这是性Neng优化的核心魔法。要理解这个现象，我们需要知道浏览器内部也是“多线程”协同工作的。其中Zui重要的两个线程是主线程和合成线程。

通常情况下样式的计算、布局的排版以及 JavaScript 的执行dou在主线程上完成。但是对于 transform 和 opacity 这类属性，浏览器有一套特殊的处理机制。当主线程忙于跑那个该死的 while 循环时合成线程却在独立工作。它不断地指示 GPU 旋转那个图层，并geng新屏幕。因为合成线程不依赖主线程的计算结果，所以动画得以流畅运行，完全不受 JS 阻塞的影响。

Case B 的下场则比较惨烈。它使用的是 margin-left 来实现位移。

/* 改变 margin-left */
@keyframes pure-margin {
  0% { margin-left: 0px; }
  50% { margin-left: 150px; } /* 触发 Layout */
  100% { margin-left: 0px; }
}

死因：触发重排。

margin 属性决定了元素在文档流中的位置。修改它会影响周围元素的排版，甚至导致父元素的大小变化。浏览器必须重新计算布局，也就是我们常说的 Layout 阶段。这个计算过程必须在主线程完成。主线程忙着跑死循环，根本没空去算布局，所以动画瞬间停止。从调试图表中Ke以明显kan到，margin 会频繁触发页面的重排，而 transform 是不会的。

Case C 是一个混合体，它既使用了 transform，也改变了 width。

@keyframes mixed-transform {
  0% { transform: rotate; width: 48px; }
  50% { transform: rotate; width: 120px; } /* Width 触发 Layout */
  100% { transform: rotate; width: 48px; }
}

死因：被队友拖累。

虽然它包含 transform，但它同时也改变了 width。width 的改变会触发 Layout。浏览器通常需要每一帧dou确认 Layout 的结果，才Neng进行后续的绘制和合成。因为 width 的计算被主线程阻塞了整个动画帧的提交被延后导致即使是旋转部分也被迫停止。这就是典型的“一颗老鼠屎坏了一锅粥”。

Zui后是 Case D，它完全由 JavaScript 的 requestAnimationFrame 驱动。

// JS 驱动的动画逻辑
const animateJS =  => {
  // ...计算位置 x ...
  if  {
    jsBoxRef.current.style.transform = `translateX`;
  }
  requestRef.current = requestAnimationFrame;
};

死因：依赖主线程。

requestAnimationFrame 是请求浏览器在下一次重绘前调用指定的回调函数。请注意，这个回调函数是在主线程上执行的。当主线程被 while 循环卡死时animateJS 函数根本得不到执行机会。所以即便你操作的是 transform，只要是通过 JS 在主线程上同步修改样式，动画依然会瞬间冻结。

通过这个 Demo，我们Ke以得出明确的性Neng优化原则。为什么方块 A Neng突破 JS 的封锁？这得益于现代浏览器的分层渲染机制。

当浏览器遇到 transform 或 opacity 动画时它会尝试将该元素提升为一个独立的合成层。这个层就像是一张透明的胶片，被单独送交给 GPU 处理。GPU 不需要关心页面的布局结构，它只需要知道“把这个胶片旋转多少度”或者“把这个胶片变透明多少”。

此时无论主线程是在跑死循环，还是在进行复杂的计算，合成线程dou在独立工作。它不断地指示 GPU 旋转那个图层，并geng新屏幕。这就是为什么即便你的 JS 卡死了Loading 转圈动画依然在转。

相反，像 marginwidthlefttop 这些属性，它们属于布局属性。一旦改变，浏览器必须重新计算整个页面的几何结构，这是一个昂贵的操作，而且必须在主线程完成。主线程一忙，渲染就断。

理解了原理，我们该如何应用到实际项目中呢？请立刻检查你项目中的 Loading 组件或过渡动画。

确保它们是基于 CSS transform 实现的，而不是 JavaScript 或 margin。这样，即使你的后端接口返回慢，或者前端数据处理卡顿，用户依然Nengkan到一个丝般顺滑的加载指示器，从而减少“应用Yi崩溃”的错觉。

试想一下Ru果用户在等待数据时Loading 圈圈也卡住了他们会怎么想？他们会认为浏览器彻底死机了甚至直接关闭页面。但Ru果圈圈还在转，他们就会认为“数据还在加载中”，耐心就会多维持几秒。这几秒的体验差异，可Neng就是用户留存的关键。

当然性Neng优化是一个庞大的系统工程。除了关注动画的渲染线程，我们也不Neng忽视其他方面的影响。

例如CSS 资源的加载本身也会阻塞页面的渲染。CSS 加载会阻塞后面 JS 语句的执行，这是因为 JS 可Neng会操作 DOM 样式，所以浏览器必须等待 CSS 解析完成。此外合理的使用缓存也Neng显著提升性Neng。不过要注意一个问题，就是文件geng新后你要避免缓存带来的影响，确保用户总是Neng获取到Zui新的代码。

在前端开发中，我们常听到另一条性Neng优化建议：“尽量使用 transform 和 opacity Zuo动画”。这不仅仅是为了减少重排，geng是为了利用浏览器的多线程特性，实现真正的Off Main Thread Animation。

通过这个 Demo，我们kan到了浏览器内部“多线程”协作的冰山一角。JS 主线程虽然强大，但也是性Neng瓶颈的高发区。学会将动画任务剥离出主线程，利用合成线程和 GPU 的力量，是每一位高级前端工程师的必修课。

下次当你遇到页面卡顿，或者在设计复杂的交互动画时请记住那个在死循环中依然顽强旋转的方块 A。那是浏览器留给我们的逃生通道，也是通往极致性Neng体验的钥匙。