前端性能优化是拆出来的不是堆出来的

上周跟做了六年前端的朋友吃夜宵，他把冰可乐碰得哐当响，说刚被业务方追着骂了一下午。页面打开要三秒，竞品才一秒不到。他熬了三个晚上改打包配置，压图片，拆包，跑Lighthouse拿了92分，结果用户反馈的速度还是没变化。 我啃了一口烤串，没接话。 太熟悉了。

先搞清楚你在优化什么

很多人一碰到性能问题，第一反应是打开性能工具跑一遍，照着上面的红项挨个改。图片没压缩就压，脚本没异步就加async，缓存时间短就拉长。忙活一周，分数涨了，用户该嫌慢还是嫌慢。 你得先搞清楚，用户等的到底是什么。首屏可交互时间的权重，从来都比整页加载完成时间高。 举个最常见的例子。有个团队把首页所有图片都转成了webp，体积直接砍了70%，算下来首屏总加载时间少了近一秒。结果因为懒加载的判断逻辑直接绑在scroll事件上，没做节流，用户一滚动，主线程被高频触发的判断逻辑占满，直接卡成PPT。用户感知到的“慢”，比优化之前还强烈。

说白了，你优化的从来不是测试工具上的冰冷分数，是用户从点下链接到能正常输入、点击、读到核心内容的那几秒。那些花里胡哨的装饰图，哪怕加载慢个两秒，用户根本不会在意。但要是核心按钮点了没反应，核心文字加载不出来，哪怕你整个页面的总加载时间再短，用户也会觉得这个网站慢得要死。

那些没人跟你算的优化代价

别信那些列满优化技巧的清单。每一条优化手段，背后都藏着你要付的成本。 就说路由懒加载。确实，首屏包体积砍下来了，加载速度快了。代价是什么？每多切一个路由，就要多等一次动态脚本的加载。弱网环境下，用户点个跳转，白屏等个几百毫秒，比你一开始把整个包打进去的体验还糟。 还有预加载。听着很美好，把用户可能要访问的页面提前拉下来，切的时候秒开。但你算过带宽占比吗？你提前拉的那些资源，会挤掉首屏核心资源的加载优先级。本来核心脚本应该先加载的，结果被你预拉的次要资源堵在队列后面，首屏时间反而变长。 我之前见过一个项目，恨不得把所有能开的优化开关都拉满：代码分割、图片懒加载、第三方脚本异步、预连接所有CDN域名、资源提示全加上。最后一查请求瀑布图，首屏的请求数从原来的30个涨到了87个，光DNS查询的时间加起来，就占了首屏总时间的四分之一。 麻烦在于，每加一层优化逻辑，就多一个可能出bug的节点。比如你给懒加载的图片设了占位符，忘了给核心图设置固定宽高比，图片加载的时候直接把下面的文字顶下去，用户刚读到一半的内容突然跳位置。这种体验，比你慢个几百毫秒还让人火大。

别上来就推翻现有架构

我见过太多团队，一碰到性能问题，第一反应是要重构。要换SSR，要上边缘计算，要把整个项目的代码全写一遍，搞一套“极致优化”的新架构。 真的没必要。 之前有个项目，首屏加载要3.2秒，团队算了下，重写SSR要花三个月。结果技术负责人花了半小时排查，发现慢的根源根本不是前端框架的问题：首页接口返回了200多K的无关字段，前端拿到数据之后，循环遍历了三次做数据清洗，光JS执行时间就占了首屏的1.2秒。后来把接口的无关字段砍到30K，把数据清洗的逻辑挪到后端，整个改动不到一百行代码，首屏时间直接降到1.4秒。 前端性能优化的第一优先级，永远是找最容易改、改完收益最大的那几个点。 先查有没有阻塞渲染的同步脚本，有没有没设长期缓存的静态资源，有没有重复打包的同一个依赖，有没有在主线程上跑的大循环。这些点的改动成本极低，往往能拿到80%的优化收益。那些上来就说要重构架构的，多半是没耐心蹲下来看具体的问题。 我之前真见过一个团队，为了追Core Web Vitals的满分，花了半个月把原来的CSR项目重写成SSR。结果因为服务器端渲染的接口响应慢，加上 hydration 阶段的JS执行卡主线程，首屏可交互时间比原来的版本还慢了400毫秒。最后闹得没办法，又花了一周把代码全回退了。图啥呢。 最近总有人把Core Web Vitals的指标当成金科玉律，说必须把LCP压到2.5秒以内，INP压到200毫秒以内，才算合格的优化。但很少有人说，这些指标的阈值是针对普通内容站点定的。如果你的产品是个在线设计工具，首屏要加载几百K的编辑器逻辑，硬要把LCP压到阈值以内，就得把核心的编辑功能拆成好几块，等用户要用到的时候再加载。这种为了凑分数做的拆分，反而破坏了产品的核心体验。 前端性能优化从来不是做加法，不是你把所有听说过的优化技巧都堆上去，就能拿到好结果。它更像是拆积木，把那些挡在用户核心路径上的、没用的、冗余的东西一点点拆下来，算清楚每一步的代价和收益。 别信那些培训班吹的，什么上了这套流程就能拿满分。真的，你蹲下来看五分钟的性能瀑布图，找几个真实用户问一句“你觉得哪里慢”，比你背一百条优化技巧有用得多。