CSS动画不阻塞首屏加载但写法不当会拖慢渲染，关键在于避免未加载样式依赖、强制同步布局和冗余计算；内联仅首屏用到的动画规则，禁用background-position等触发重绘的属性，优先使用transform和opacity，并适配prefers-reduced-motion。
CSS 动画本身不阻塞首屏加载，但写法不当会拖慢首屏渲染。关键不在“有没有动画”，而在于动画是否依赖未加载的样式、是否触发强制同步布局、是否在关键路径上引入冗余计算。
内联关键 CSS 时别把动画规则全塞进去
很多人提取 Critical CSS 时，把 @keyframes 和动画类（如 .loading-spin）一股脑内联，结果增大了 HTML 体积，还可能因浏览器提前解析大量无用动画逻辑而延缓首次绘制。
- 只内联首屏真实用到的动画规则（例如骨架屏 shimmer 的
@keyframes shimmer），其他动画延迟加载 - 避免内联带复杂选择器的动画类（如
.card:nth-child(2n) .avatar:hover .ring），它们增加 CSSOM 构建时间 - 用
Chrome DevTools → Coverage 面板检查哪些动画规则在首屏根本没执行，直接剔除
shimmer 动画必须用 opacity + transform，禁用 background-position
常见错误是用 background-position 实现光效扫动——它会频繁触发重绘（paint），且无法硬件加速，在低端设备上极易掉帧。
@keyframes shimmer {
from { transform: translateX(-100%) scaleX(0.5); opacity: 0.3; }
to { transform: translateX(100%) scaleX(0.5); opacity: 0.8; }
}
.skeleton {
animation: shimmer 1.8s infinite;
/* ✅ 正确：仅用 transform + opacity */
/* ❌ 错误：background-position: 0 0; → 触发 paint，无 GPU 加速 */
}- shimmer 动画时长控制在
1.2s–2.5s，太短用户感知不到“正在加载”，太长显得卡顿 - 避免对
width、height或background-size做动画——这些属性强制重排（reflow） - 若用伪元素实现 shimmer（如
::after），确保其contain: layout paint，隔离渲染影响
prefers-reduced-motion 不只是“关动画”，更是性能开关
开启“减少动画”的用户，往往也处于低功耗模式或使用中低端设备。此时不仅应停掉 shimmer，更应跳过整个骨架屏渲染逻辑，直出占位结构。
立即学习“前端免费学习笔记（深入）”；
- 用
@media (prefers-reduced-motion: reduce)直接将动画设为animation: none，并移除transform等合成层提示 - JS 中可监听
matchMedia('(prefers-reduced-motion: reduce)')，动态切换加载策略（例如跳过骨架屏，直接显示loading...文本） - 不要只靠 CSS 降级：某些骨架屏组件（如 React 的
Skeleton）内部仍会执行 DOM 插入和尺寸测量，需 JS 层配合裁剪
最容易被忽略的是：动画不是独立模块，它嵌在渲染链路里。一个 transform: scale(1.01) 的微动效按钮，如果出现在首屏核心按钮上，又没加 will-change: transform 提示，就可能让浏览器反复升层、降层，反而比不动还慢。
