前端性能优化别被跑分绑架

上周珠江路拐角的咖啡馆，1024南京社群的线下小聚，碰着个老同事。 刚熬了三个通宵。 他把自家C端产品的首屏加载时间从4.2秒硬压到1.1秒，上线当天就被运营堵在工位上——为了压包体积，他把首页跳转活动的弹窗资源拆到了二级页面加载，之前用户进首页等三秒才弹的满减券，现在直接丢了触发时机，当天的活动核销率掉了快四成。 周围一圈人听完都笑。笑过了才觉出味来：前端性能优化从来不是技术部门关起门来对着指标刷分的事，从一开始就绑着业务的弦。

别拿实验室跑分当最终答案

很多人对前端性能优化的认知，还停留在打开Lighthouse跑个分，把分数刷到95以上就拍胸脯交差。 这事没那么玄。 实验室环境是什么？千兆光纤，干净的浏览器缓存，无插件的全新浏览器，跑在最高配的Mac上。可真实用户呢？是早高峰挤在地铁里刷网页的2G弱网，是开了二十个标签页内存占满的老版本Chrome，是用了三年、装了半页预装APP的千元安卓机。

为了凑实验室的高分，很多团队把所有图片都转成最高压缩比的WebP，却忘了部分老版本的国产浏览器根本不支持这个格式，用户打开就是满屏裂图；为了把可交互时间压到两秒以内，把首屏所有非核心JS都延迟加载，结果把新手引导的触发逻辑也卡到了用户划走半屏之后，引导转化率掉了两个点——算下来的流失，比加载慢带来的损失还大。 所有脱离真实用户行为的性能优化，本质上都是自嗨。 别总盯着工具给的数字。你后台采的真实用户数据，比实验室跑分的参考价值高十倍。

大部分优化根本不需要动核心代码

一提到前端性能优化，很多人第一反应就是要上SSR，要换最新的框架特性，要把整个打包流程推翻重写。 真没必要。 80%的常见性能问题，根本藏在最容易被忽略的边角里。上次碰着个团队，首页加载慢到要等五秒，翻了半天打包日志才发现，他们为了图方便，直接全量引入了一个近400KB的UI组件库，可整个页面只用到了三个按钮组件。换成按需引入之后，光这一块就砍掉了380KB的体积，首屏加载时间直接降了1.3秒，连一行业务代码都没改。

还有的团队，盯着加载时间的小数点抠了半个月，却忘了给所有图片设置固定的宽高比。用户点进页面的时候，图片加载完会把下面的文字顶下去，来回跳两次，哪怕所有资源都在一秒内加载完，用户也会觉得卡。 布局偏移带来的卡顿感，比资源加载慢给用户的负面感受强三倍。 说白了，很多人总想着搞大动作，却不愿意蹲下来看看最基础的配置有没有漏。

别为了优化把可维护性全丢了

我见过太多走极端的团队。 要么完全不管性能，用户在社群骂到破防了，才想起来要拉个优化的专项；要么为了把性能指标压到极致，把整个项目搞成谁也碰不得的黑盒。之前有个团队为了把JS体积降到最小，把所有变量名都改成a、b、c，把所有判断逻辑压缩成单行，连一行注释都不留。上线之后体积是降了60%，可过了三个月，新来的同事根本看不懂代码，改个小bug要花两天时间，本来一天能解决的线上问题，因为代码太绕，排查的时候又搞出两次额外的加载错误，算下来的开发成本，比省下来的带宽钱多了十倍都不止。

前端性能优化从来不是越极致越好。你得算投入产出的账。花一周时间把JS体积再砍20KB，换来的加载时间提升可能只有0.1秒，可这一周的开发时间，本来可以用来修三个用户反馈的高频功能bug，哪个价值更高，算得清的人都不糊涂。 性能优化是服务于业务和用户的工具，不是用来凑KPI的数字游戏。 上周那个被运营堵工位的老同事，后来把弹窗的逻辑改了。没把资源全塞回首屏，而是在用户划到弹窗对应的页面位置时，再动态加载对应的资源。既没多占首屏的加载体积，也没丢活动的触发时机，两边都满意。 其实事就这么简单。 没有什么一招制胜的魔法。你蹲在真实用户的使用场景里多摸几次，多看看后台采上来的真实数据，别总盯着实验室里的跑分表，比你翻十篇网上的优化大全有用得多。