你的网站加载动画，是不是正在悄悄赶走用户？
别笑——你那个“优雅”的加载转圈，可能正让用户在第三秒就划走了。
不是他们没耐心，是手机发烫、页面卡住、手指一滑就顿住……这些细节，比你想象中更早决定用户留还是走。
为什么CSS动画的“性能友好”是公认的？
现代浏览器对 CSS 动画真有偏爱。尤其是用 transform 和 opacity 做的动画，浏览器会直接交给 GPU 处理，不占用主线程。
JS 一忙起来，比如在算优惠券、拉接口、跑埋点，主线程就堵着。这时候 JS 动画很容易掉帧、跳变、甚至卡死。而 CSS 动画照常丝滑——它根本不管你在忙啥。
之前改过一个电商网站的“加入购物车”飞入效果。原先是 JS 控制元素位置，大促期间页面脚本一多，动画直接变幻灯片。换成纯 CSS 的 transform: translateX() 后，飞入动作立刻稳了，连运营都说“加购手感顺多了”。
JS动画的“控制力强”体现在哪里？
CSS 适合“我想让它从 A 到 B，花 300ms，带点缓动”这种干净利落的交代。
JS 则适合“用户拖到哪，它就跟到哪；松手瞬间回弹，还要根据拖动速度决定弹多远”这种边走边想的活儿。
比如滚动视差：背景图慢半拍，内容层快一步，中间还夹着一层文字要渐显——CSS 关键帧写不出来这种“实时算、随时调”的节奏。
再比如数据仪表盘：用户点选“近7天”，图表从左往右展开；换“近30天”，就得改成螺旋式浮现。这种动态路径，靠 JS 算每帧位置 + requestAnimationFrame 才能灵活应对。
对搜索引擎SEO，哪种方式更“安全”？
爬虫不会等 JS 加载完才开始读内容。
如果一个加载动画背后，是 JS 把整个商品列表“画”出来的（比如 document.createElement 拼 DOM），那爬虫很可能只看到空容器——首页不收录、搜索不露脸，很常见。
但如果是 CSS 动画：HTML 里商品已经存在，只是用 opacity: 0 + transition 控制淡入，爬虫扫一眼就全拿到了。
屏幕阅读器也一样：它依赖的是 HTML 结构和语义，不是你用了什么动画库。
所以别问“动画好不好看”，先问一句：“关掉 JS，用户还能不能看到核心信息？”
移动端用户体验的“烫手山芋”怎么解决？
手机不是缩小版电脑。它散热差、CPU 弱、电池金贵。
一个用 left/top 频繁重排的 JS 动画，在 PC 上只是微卡，在手机上就是“手指一滑，页面纹丝不动”。
我们团队做过的几个资讯类 H5，把所有列表项入场动画从 JS 改成 CSS transform + transition 后，iOS 用户反馈“终于不发热了”，安卓低端机滑动也跟手了不少。
原则很简单：按钮点击态、卡片淡入、下拉刷新指示器……这类“有始有终、无交互”的视觉反馈，一律交还给 CSS。JS 只干它该干的活：监听手势、计算逻辑、触发状态。
如何在实际项目中做出“明智选择”？
下次写动画前，花 10 秒问自己两个问题：
这个动画需要响应用户操作吗？（比如拖拽、悬停、滚动位置变化）
→ 如果不需要，闭眼选 CSS。它的起点和终点固定吗？中间过程要不要实时调整？
→ 如果全程可控、无需干预，CSS@keyframes或transition足够。
真要用 JS，优先选 requestAnimationFrame + 直接改 transform，避开 width/height/margin 这些触发重排的属性。老项目里那些用 setInterval + top++ 的写法，趁早删了。
混合用也完全 OK：CSS 负责“动起来”，JS 负责“什么时候动、动几次、动完切什么状态”。
今天下班前，就能完成的一个检查动作
打开 Chrome 开发者工具（Mac 快捷键 Cmd+Opt+I，Win 是 Ctrl+Shift+I），切到「Elements」面板。
随便点一个带动画的按钮或加载图标，看它的样式：如果看到 animation、transition 或内联 style="transform: ..."，说明是 CSS 在干活；如果看到 onclick 里调了 animate() 或 addClass('animate-in')，大概率是 JS 驱动的。
挑出 1–2 个最常出现的简单动画（比如顶部导航栏下拉、文章卡片淡入），用 CSS 重写一遍。
改完后按 Cmd+Shift+P（Win 是 Ctrl+Shift+P），输入 “Performance”，点录制 3 秒，对比前后 FPS 和主线程占用——你会立刻看清，哪一行代码在偷偷拖慢你的页面。