慢一点：关于网页性能与体验的平衡

先承认一件事：我们都偷偷喜欢动效

做这行久了，很难不对动效上瘾。一个卡片在你滚动到它时缓缓浮起，一个按钮被按下时有恰到好处的回弹，一段文字逐字显现——这些瞬间会让人觉得「这个网站是有生命的」。我自己第一次用 GSAP 做出一段滚动叙事时，盯着屏幕来回滚了二十多遍，像个孩子。

但上线两周后，一位用户在反馈里写了一句话，我记到现在：「你们的官网很漂亮，但我用手机打开,等首页那个动画转完我已经划走了。」那一刻我意识到，我做的不是体验，是我自己的炫技欲。

动效的代价，往往藏在你看不见的设备上

在一台插着电、开着 Chrome 的 M 系列 Mac 上，几乎任何动效都是丝滑的。问题是,你的用户里有相当一部分人,用的是三四年前的中端安卓机,在地铁里、信号时好时坏、电量还剩 18%。

我后来养成一个习惯：任何带动效的页面,上线前都用 Chrome DevTools 把 CPU 降到 4x 或 6x slowdown 再走一遍。很多看起来「轻盈」的效果,一降速就原形毕露——滚动掉帧、文字闪烁、整页卡顿。最常见的元凶不是动效本身,而是动错了属性:去动 width、height、top、left 这类会触发重排的属性,浏览器每一帧都要重新计算布局。把它们换成 transform 和 opacity,让动画跑在合成层上,卡顿往往一下就消失了。

动效不是用来证明「我们会做动效」的，它是用来回答用户心里那个没说出口的问题：刚才发生了什么，接下来会怎样。

判断一个动效该不该留下

我现在评估一个动效,只问一个问题:它在帮用户理解,还是只在帮我表演?

帮助理解的动效是有功能的:页面切换时的过渡,告诉用户「你从哪来、到哪去」;表单提交后的状态变化,告诉用户「系统收到了」;列表项删除时的滑出,告诉用户「这条真的没了」。这些动效哪怕只有 200 毫秒,也在悄悄降低用户的认知负担。

而纯表演的动效是另一回事——首屏强制播放三秒的开场动画、每个元素入场都要错落飞入、鼠标划过就满屏粒子。它们第一次看新鲜,第二次嫌烦,第三次用户已经在找「跳过」按钮了。一个朴素的判断标准:如果这个动效用户每天要经过十遍,它还让人愉快吗?

几条我自己在用的取舍

第一,给动效设预算,而不是设上限。我会把首屏的 LCP 控制在 2.5 秒内当成硬线,任何拖慢首屏的动效都要让路——哪怕再好看,也放到首屏之后再加载。重的库就动态 import,别让一个开场动画拖累整站的加载。

第二,永远尊重 prefers-reduced-motion。有些用户对动效会产生生理性的眩晕,这不是少数派的矫情。一行媒体查询,把大幅度的位移和缩放降级成简单的淡入,是最低成本的体面。

第三,时长宁短勿长。大多数界面过渡,150 到 300 毫秒就够了。超过 400 毫秒,用户感受到的不是优雅,是迟钝。慢动作适合电影,不适合一个要被点几百次的按钮。

「慢一点」,其实是让用户快一点

这篇手记叫「慢一点」,但它真正想说的是:我们做设计的人,要慢一点、克制一点,用户才能用得快一点、顺一点。

好的性能不是冷冰冰的数字游戏。一个能在弱网下两秒打开、滚动不掉帧、动效恰到好处地解释了正在发生什么的页面,本身就是一种温柔。它不喧哗,但它尊重每一个不在你这台高配机器前的人。

所以下次当你又想加一个酷炫的效果时,不妨先慢一点,问问自己:这是为了用户,还是为了我自己想看的那个 demo?想清楚了,再动手也不迟。