#优质博文 #CSS #前端 #性能优化 #Chrome #浏览器
从性能角度来看，对 CSS width 和 height 进行动画处理是不好的，因为它会导致渲染管线中发生布局操作（也称重排）。这一点至今仍然正确。
但最近， Chrome Canary 版本中最近有一个令人兴奋的动画/性能改进：
Animating CSS width or height no longer forces a Main Thread animation (in Chrome, under the right conditions)
[以下是方便搜索索引的大纲(AI 生成)，请读原文]
author Bramus!
从性能角度来看，对 CSS width 和 height 进行动画处理是不好的，因为它会导致渲染管线中发生布局操作（也称重排）。这一点至今仍然正确。
但最近， Chrome Canary 版本中最近有一个令人兴奋的动画/性能改进：
在 Chrome 144.0.7512.0（当前 Canary 版本）中，我们扩展了 width / height 检查，以检查 width 或 height 是否真的发生了变化。
如果 width / height 不变，则无需计算布局，因此也无需强制动画在主线程上运行。
Animating CSS width or height no longer forces a Main Thread animation (in Chrome, under the right conditions)
AI 摘要：文章介绍了 Chrome Canary（144.0.7512.0 版本）在动画性能上的新改进：当 width 或 height 在关键帧中并未实际变化时，动画不再被强制在主线程运行，而是可在合成线程（Compositor）上执行，从而显著提升性能。该优化改变了 Blink 对动画可合成判断的逻辑，对视图过渡（View Transitions）等场景尤其有利。作者也讨论了后续可控方案、兼容性影响与手动优化替代方法。
[以下是方便搜索索引的大纲(AI 生成)，请读原文]
1. 性能与动画基础
• 解释为何过往 width / height 动画会触发 Layout，必须在主线程执行
• 说明渲染管线（rendering pipeline）中 Layout 的代价
• 传统认为应避免对这些属性做动画
2. Chrome 新改进（从版本 144.0.7512.0 开始）
• Blink 引擎增加了判断逻辑：若关键帧中 width / height 值不变，则动画可在合成线程上运行
• 展示了新旧判断流程图差异及其性能收益
• 对视图过渡动画（::view-transition-group(*)）的直接正面影响
3. 实现细节与特殊情境
• 介绍设计判断逻辑时考虑的复杂情境，如隐式关键帧、auto 值等
• 提及其他浏览器（Firefox、Safari）尚未有类似优化
• Blink 团队确保多种 CSS 表达形式都在判断范围内
4. 后续展望与开发者优化建议
• 链接至 W3C 讨论提案 w3c/csswg-drafts#13064，计划为开发者提供更多控制
• 提出当前自我优化方案：用 scale 动画取代宽高变化
• 引用了 Google Search 实际应用与 Motion 框架在变形修正上的做法
5. 影响与意义
• 此更改让许多原本“卡顿”的过渡动画直接获得加速
• 鼓励社区和其他浏览器跟进，共同提升 Web 动画性能
author Bramus!
