前端性能优化的实用技巧

前端性能优化这事，听着玄乎，其实就是“别让用户等”

上周朋友拉我看他新上线的活动页，说是“设计很酷、交互很炫”。我拿手机点开，首页先白了两秒，接着图片一块块像拼图一样慢慢冒出来，按钮点下去还没反应，我还以为手机卡了。朋友在旁边尴尬地笑：“可能服务器今天慢。”其实服务器才背了一半锅，另一半是前端没扛住。性能不好的时候，最先被骂的永远是“网太差”，可用户根本不管谁锅谁碗，他们只记得“这个站难用”。所以性能优化不是锦上添花，而是先别把门关死。

我见过不少团队把优化想得太重，非得等项目收尾才想起来“要不要压一下包”。结果时间紧、改动大，最后也就是压缩几张图、凑合上线。真正有用的优化，是从第一行代码就开始计较：资源多大、什么时候要、要不要现在要。就像过日子，不一定顿顿大鱼大肉，但别让锅一直空烧着。优化的目标其实特别朴素：让页面“看起来快、用起来顺、收手不费劲”。

还有一点，性能是有场景的。管理后台卡几秒，管理员忍了；可电商首页卡两秒，购物车就凉了。几年前我做过一个新闻类小程序，首页首屏控制在两秒内，跳转再快一点，留存直接往上走。那时候我们没加什么黑科技，只是把“不着急做的事往后挪，把要紧的事往前放”。后来复盘发现，用户对“快”的感知，往往比真实性能还主观：你哪怕只先出个骨架屏，心理上就觉得顺了。

性能问题最烦人的地方，是它经常藏得很深。开发时跑得好好的，一上线就慢，换机型、换网络、换地区，表现还不一样。有一回我们上线新功能，测试怎么测都流畅，结果一到真实用户手里，动画就开始掉帧。后来抓日志才发现，是某些机型下字体加载把渲染堵住了。你看，性能就像水管，平时不漏水不代表没隐患。你得常拧一拧，别等漫出来才想起修。

从“能跑就行”到“先跑顺再说”

很多性能问题，其实是被“好看的代码”拖慢的。比如组件库全家桶，不管用不用，先全装进来；路由全静态引入，点哪个页都打包一堆不相关的代码。我之前接手一个项目，首屏 JavaScript 就快两兆，移动端直接劝退。后来我们把非首屏的页面拆成异步加载，首屏体积砍掉三分之一，首屏时间肉眼可见地掉。这种改动不需要重写业务逻辑，只需要一点“克制”。

克制说起来容易，做起来常被需求推着走。产品说“先都放进去，以后再说”，运营说“多几张图才吸引人”。这时候性能优化要做的不是对抗，而是给出一个“代价看得见的选项”：多放两兆，意味着首屏可能慢多少，弱网下失败率涨多少。如果数字摆在面前，沟通会顺畅很多。性能优化很多时候不是技术问题，是优先级问题：你愿意为用户等多久，你自己愿不愿意等。

还有一个常见误区，是把“优化”等同于“压缩”。压缩当然有用，但只靠压缩救不了结构性的问题。比如图片体积再小，如果同时请求几十张，拼在一起照样堵。真正见效的做法，是先做减法：不用先别放，能懒就懒，能小就小。减法做完了，再谈排序、缓存、预加载。很多时候，减一减比压一压效果好得多。

网络与资源：先谈“要不要”，再谈“怎么送”

前端离网络最近，也最容易在网络这关上吃亏。早些年我们都迷信“打包成一个文件，减少请求”，现在回头看，这种思路在 HTTP/1 时代或许有用，但在 HTTP/2 和 HTTP/3 环境下，合理拆分、并行加载反而更稳。重点不是“拼得多紧密”，而是“送得对不对”。

图片依然是大头。现在很多项目还在用全尺寸图配 CSS 缩放，既费带宽又费渲染。更稳的做法是按需输出尺寸，配合现代格式和懒加载。有一回我们把商品图从 JPEG 统一换成 WebP，体积直接掉一半，弱网下的首屏稳定了不少。更进一步的是用 CDN 做自动裁剪和格式兜底，不同设备拿到的图刚好合适，不多也不少。

字体也是容易被忽视的坑。尤其是中文站点，动辄几兆的自定义字体，用户没看完内容就先等字。等不是办法，拆才是。我们后来把字体按需切割，常用汉字优先加载，剩下走异步兜底。视觉上先保证可读性，体验不会断崖式下跌。

缓存策略是“稳”的来源，却经常被当成运维的事。其实前端能不能控制缓存、能控制到什么程度，直接决定用户是“每次都白等”还是“像本地一样快”。合理使用强缓存和协商缓存，配合版本号或内容指纹，能在不影响发布的前提下，把重复请求压到很低。这事看起来不起眼，但日积月累，省下的流量和时间很可观。

渲染与交互：让用户觉得“快”比真的“快”更重要

性能不只是数字，更是感受。有时候页面并没有快多少，但你只要先给用户一个“回应”，他的耐心就能多撑几秒。骨架屏就是这么一种“温柔的谎言”：我不给你完整内容，但先给你结构，告诉你别急。

渲染节奏同样重要。一次把太多节点怼进 DOM，浏览器会卡，用户会觉得“顿”。分批上屏、用时间切片、优先把首屏内容刷出来，剩下的再慢慢填，体验会顺很多。我们在一个长列表页做过实验，把渲染拆成两到三批，交互响应时间没变，但用户投诉明显下降。可见“顺”比“短”更重要。

交互上的性能问题，往往出在看不见的地方。比如频繁触发的滚动和缩放事件，如果没有做防抖或节流，CPU 会一直在高负荷。用户看到的是“滑不动”，开发者看到的却是“没报错”。这种问题在低端机型上会被放大，而在旗舰机上被掩盖。所以测试不能只在好设备上做，条件差一点的环境才是试金石。

动画也是性能大户。很多时候动画不是为了功能，而是为了“好看”。好看可以有，但得有代价意识。用 CSS 硬件加速的属性能带来明显收益，而动辄触发重排的动画会让页面越动越慢。适当克制，动画才是加分项；一上头，就是减分项。

工具、监控与持续优化的习惯

最后，性能优化如果只靠“人肉”，是很难持续的。你这一次改得好，下一次加个功能，性能又回去了。所以要依赖工具把底线守住。打包体积分析、首屏耗时跟踪、长任务监控，这些都应该作为日常报表的一部分，而不是上线前突击的项目。

真实用户监控尤为重要。开发环境再快，快不过本地模拟器；真实用户的网络、设备、行为才是最终答案。把性能指标和发布流程挂钩，像对待错误日志一样对待性能回退，团队才会形成“条件反射”：加东西之前先问一句“负担有多大”。

结语

前端性能优化不是一场冲刺，而是一种习惯。它不来自一两句“黑科技”，而来自无数次“多此一举”的克制：多此一举拆包、多此一举压缩、多此一举把不重要的往后挪。结果就是，用户不会注意到你做了什么，只会感觉到“这个站用着真顺手”。

性能好的页面，像一条不堵车的高速公路，你甚至意识不到它的存在。而一旦它变慢，抱怨就来了。作为开发者，我们能做的不多，但能把“等”的时间一分一分抢回来，就已经值了。项目会结束，需求会变更，但对“快”的追求，值得一直做下去。