Front-End-Checklist 的 animation-performance 规则只用 transform 和 opacity 做 GPU 合成动画【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist本文基于 Front-End-Checklist 仓库中的 animation-performance 技能文档 及其 完整规则参考系统讲解“动画只用transform和opacity”这一 CSS 性能规则的判定依据、改写方法位置动画转translate()、尺寸动画转scale()与验证步骤并结合仓库中生成该技能的脚本和 MCP 代码审查工具的实现展示该规则如何被机器自动执行。读完后你可以独立执行这条规则的四步审查流程Check / Fix / Explain / Code Review并能对照仓库源码验证其自动化检测逻辑。规则定位一条面向 AI Agent 的 CSS 性能审查技能animation-performance是 Front-End-Checklist 项目中css类别下的一条审查规则仓库中以“技能”skill形式存在。其 SKILL.md 的 frontmatter 声明了规则元数据字段值含义categorycss归属 CSS 规则类别priorityhigh高优先级规则difficultyintermediate中等难度estimatedTime20预计审查耗时 20 分钟sourcefrontendchecklist.io规则来源站点技能文档的核心判断依据写在正文首段动画若作用于布局属性width、height、top、margin每一帧都会触发浏览器完整的渲染管线——样式重算、布局、绘制与合成该过程运行在主线程上会与 JavaScript 争抢资源而动画只作用于transform和opacity时布局与绘制步骤被完全跳过动画运行在 GPU 专用合成线程上即使主线程繁忙也能保持 60fps。SKILL.md 还包含一条 Quick Reference快速参考清单浓缩了四条判定要点只有transform和opacity能在不触发布局的前提下被 GPU 合成will-change: transform应谨慎使用用于把元素提升为独立的合成层简单动效优先使用 CSS 过渡和动画而不是 JavaScript 动画库必须响应prefers-reduced-motion为需要的用户关闭动画。技能文档本身遵循统一的骨架Check找出动画布局属性的 CSS 并标记、Fix把布局属性动画改写为transform等价物位置变化用translate()尺寸变化用scale()、Explain解释浏览器渲染管线、transform/opacity为何高效、GPU 合成器如何工作、Code Review审查样式表、组件样式与响应式状态标记违规的具体选择器、声明或断点。从仓库结构看这份技能文档并非手写维护而是由 generate-skills.ts 从规则的 MDX frontmatter 自动生成脚本读取 packages/content/rules/en/css/animation-performance.mdx 中的title、tldr、promptscheck / fix / explain / codeReview等字段分别拼出 SKILL.md 的 frontmatter、Quick Reference 与四个提示词小节再把 MDX 正文去掉 JSX 语法后转为纯 Markdown 写入references/rule.md。脚本头部注释也说明了安装方式通过npx skills add frontendchecklist/skills可整体安装加--skill {slug}可只安装单条规则。原理渲染管线中的“三层属性”完整规则参考references/rule.md开篇即给出核心模型浏览器通过 Style → Layout → Paint → Composite 管线渲染页面。动画选错属性会让这条管线每帧重启一次而只动画transform和opacity时仅触发最后的 Composite 步骤。规则把 CSS 属性按动画成本分为三档这是审查时的核心判定表触发 Layout 的属性避免做动画 width, height, margin, padding, top, left, right, bottom, border-width, font-size, display, position 触发 Paint 的属性可接受但非理想 color, background-color, box-shadow, border-color, outline, text-shadow 仅触发合成器的属性动画最优 transform (translate, scale, rotate, skew) opacity filter在已合成层上理解这张表的要点Layout 触发属性改动它们会改变盒模型或文档流浏览器必须重新计算整个布局树是动画中最昂贵的路径Paint 触发属性布局不变但需要重新绘制像素成本居中Compositor-only 属性transform和opacity不改变元素在布局中的位置与尺寸只需 GPU 合成器对已有图层做位移/缩放/透明度过渡因此即使主线程阻塞长任务、同步 JS动画也不会卡顿。filter在已提升为独立层的元素上同样可以走合成器路径。Check如何判定一段 CSS 动画违规SKILL.md 的 Check 提示词给出的标准是找到文件中的 CSS 动画或过渡若它们动画了top、left、width、height、margin等触发布局的属性则标记为需要优化。仓库中 MCP 代码审查工具对该规则实现了自动启发式检测。review-code.ts 中针对animation-performance的逻辑维护了一个“昂贵属性”清单并在命中时结合will-change的存在与否给出结论// animation-performance — animating expensive CSS properties (box-shadow, filter, clip-path) if (slug.includes(animation-performance)) { const EXPENSIVE [ box-shadow, filter, clip-path, border-radius, background-color, background ] const hasExpensiveAnimation EXPENSIVE.some( prop new RegExp(keyframes[\\s\\S]*?${prop}\\s*:, i).test(code) || (lowerCode.includes(animation) lowerCode.includes(prop) !lowerCode.includes(transform) !lowerCode.includes(opacity)) ) if (hasExpensiveAnimation !lowerCode.includes(will-change)) { return { hasIssue: true, issue: Animating expensive CSS properties (box-shadow/filter/clip-path) — prefer animating transform and opacity for GPU-composited animations } } }从源码结构看自动检测的判定逻辑是双条件的检测昂贵属性是否被动画正则检查keyframes块内是否出现box-shadow、filter、clip-path、border-radius、background-color、background任一属性或者代码中同时出现animation与昂贵属性、却不含transform或opacity结合缓解手段即使命中昂贵属性动画若代码中已有will-change则不判定为问题——这与规则文档“will-change可提前把元素提升为独立层”的说明相呼应。值得注意的是这份自动检测清单与 SKILL.md 的 Check 提示词是互补关系提示词关注的是布局触发属性top、left、width等成本最高而启发式代码额外覆盖了非合成的 Paint 类属性box-shadow、filter等两者合起来构成对“动画属性选择”的完整审查面。Fix位置动画与尺寸动画的 transform 改写规则给出的标准修复策略是位置变化转translate()尺寸变化转scale()。完整规则参考中给出了两组前后对照示例。位置动画left→translateX()/* 反例动画作用于布局属性 —— 每帧触发完整 reflow */ .slide-in { animation: slideIn 300ms ease-out; } keyframes slideIn { from { left: -100%; } to { left: 0; } } /* 正例translate() 仅走合成器 */ .slide-in { animation: slideIn 300ms ease-out; } keyframes slideIn { from { transform: translateX(-100%); } to { transform: translateX(0); } }改写后元素在布局树中的位置不变left不再逐帧变化GPU 合成器只负责对图层做水平位移主线程负担显著降低。尺寸动画width/height→scale()/* 反例动画 width/height —— 昂贵 */ .expand { animation: expand 300ms ease; } keyframes expand { from { width: 0; height: 0; } to { width: 200px; height: 200px; } } /* 正例使用 scale()最终尺寸固定在元素上 */ .expand { width: 200px; height: 200px; animation: expand 300ms ease; } keyframes expand { from { transform: scale(0); } to { transform: scale(1); } }scale()方案的关键写法细节把最终尺寸width: 200px; height: 200px直接写在元素上让布局一次性完成动画只负责从 0 到 1 的视觉缩放。需要说明的适用边界是scale()改变的是视觉尺寸而非布局占位若动画期间周围元素需要跟随其占位变化则无法纯粹用scale()替代此时需要权衡或改用空间预留 缩放的方式。常用的高性能动效模式规则参考还整理了三组可直接复用的模式均只使用transform与opacity/* 淡入 */ .fade-in { animation: fadeIn 300ms ease; } keyframes fadeIn { from { opacity: 0; } to { opacity: 1; } } /* 上移 淡入缓出曲线 cubic-bezier(0.16, 1, 0.3, 1) */ .slide-up { animation: slideUp 400ms cubic-bezier(0.16, 1, 0.3, 1); } keyframes slideUp { from { opacity: 0; transform: translateY(16px); } to { opacity: 1; transform: translateY(0); } } /* 按钮按下反馈 */ .button:active { transform: scale(0.97); }这三个模式淡入、上滑淡入、按压缩放覆盖了常见的入场、加载与交互反馈场景可以作为团队动效规范的基础组件。will-change提前提升合成层但必须克制will-change是向浏览器发出的提示该元素即将动画化请提前把它提升为独立合成层避免动画首帧时浏览器临时提升图层造成的闪烁或掉帧/* 提示浏览器在动画开始前就把该元素提升为独立图层 */ .animated-card { will-change: transform; } /* 警告不要对过多元素使用 —— 每一层都消耗 GPU 显存 */ /* 最佳实践动画开始前应用动画结束后移除 */规则对此给出了明确的克制原则不要批量声明每个独立合成层都会占用 GPU 显存页面图层过多反而拖累渲染动态应用从规则注释看推荐的做法是“动画开始前通过 JS 加上、动画结束后移除”而不是在样式表中对所有潜在动画元素永久声明。这一点也与 review-code.ts 中hasExpensiveAnimation !lowerCode.includes(will-change)的判定逻辑一致——will-change在该规则的实现中同时扮演着“已做图层优化”的信号。可访问性配套尊重 prefers-reduced-motion性能规则必须与可访问性规则配套。SKILL.md 的 Quick Reference 第 4 条明确要求响应prefers-reduced-motion完整规则参考给出了两种等价写法/* 写法一动画照常声明在 reduce 媒体查询中关闭 */ .slide-in { animation: slideIn 400ms ease; } media (prefers-reduced-motion: reduce) { .slide-in { animation: none; /* 如需提供非动画的替代反馈 */ } } /* 写法二更安全仅当用户不偏好减少动画时才启用动画 */ media (prefers-reduced-motion: no-preference) { .slide-in { animation: slideIn 400ms ease; } }两种写法语义相同但写法二no-preference白名单被规则注释标注为“safe pattern”动画默认不生效仅在用户明确允许时才启用能天然规避旧浏览器不识别媒体查询时的兼容风险。仓库中与这条规则强相关的姊妹规则是 reduced-motion 技能其 Quick Reference 提醒动画不应每秒闪烁超过 3 次并建议提供暂停/关闭动画的用户控制——审查动画性能时应将两条规则结合检查。Verification上线前的验证步骤完整规则参考末尾给出了四步验证清单用于确认修复真实生效而非纸面合规在该规则影响的断点与交互状态下检查实际渲染的 UI在 DevTools 中确认计算样式computed styles与预期修复一致上线前至少测试一个移动端和一个桌面端视口若规则影响了运动、对比度或布局稳定性直接验证这些面向用户的实际效果。验证时可使用 Chrome DevTools 的 Rendering 面板观察图层与合成情况规则 MDX 的tools字段即指向该工具与prefers-reduced-motion的 MDN 文档见 animation-performance.mdx 的 frontmattertools与sources配置。规则在网络中的位置与相关规则该规则在仓库的 规则目录 中被列为css类别下的勾选项与images、accessibility、javascript、security等类别的其他高优先级规则并列是整个检查清单体系的一部分。从 animation-performance.mdx frontmatter 的relatedRules字段看规则自身声明了四条关联规则及其审查关系css-containmentCSS containment 同样限制被动画元素的渲染作用域与合成层优化互补viewport-zoom影响布局的动画可能干扰缩放的可用性dimensions两条规则同属css/performance领域通常一起审查对应 SKILL.md 中“在提出修复前检查各断点下的渲染布局”的提示词要求view-transitions两者都影响 CSS 质量常见于同一次审查。此外generate-skills.ts 的loadGlobalRuleHighlights函数会把css/animation-performance与reduced-motion、dimensions等规则一起选入全局规则亮点清单说明该规则在项目内容体系中被视作 CSS 性能方向的代表性规则之一。小结把规则落到一次代码审查中的操作路径结合 SKILL.md 的提示词骨架与仓库源码对任意样式文件或组件做一次 animation-performance 审查的完整路径是扫描定位文件中所有keyframes块与animation/transition声明核对关键帧内的属性名分级按三层属性表把动画属性归类——出现top/left/width/height/margin等布局属性即高优先级问题出现box-shadow/filter/clip-path等非合成 Paint 属性为次级问题改写位置变化换translate()尺寸变化换scale()最终尺寸固定写在元素上简单动效一律改用 CSStransition/animation而非 JS 动画库补层与克制的平衡仅在确有必要时为元素添加will-change: transform并遵循“动画前加、动画后移除”无障碍兜底用prefers-reduced-motion白名单模式包裹动画验证按四步验证清单在移动端与桌面端断点各检查一次用 DevTools 确认计算样式。完成以上六步一条动画就从“每帧重跑完整渲染管线”收敛为“合成器独立线程上的 60fps 位移动画”这正是 animation-performance 规则在 Front-End-Checklist 体系中的核心价值。【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考