上周跟一个做电商的朋友吃饭，他说他们刚花了三个月重构首页，首屏加载从4.2秒压到1.1秒，转化率涨了8%——这事听着爽，背后踩的坑能写满半本便签。
很多人一提前端性能优化，第一反应是上压缩、上CDN、换懒加载，都是网上抄的三板斧。真到自己项目里用，要么没效果，要么改完出一堆兼容问题。
别上来就堆工具，先搞清楚你慢在哪
太多人一提到优化，先打开本地的Lighthouse跑个分，看着90分以下的项就挨个改，改完沾沾自喜。
你在本地DevTools里测的加载速度，跟真实用户在地铁里刷到的速度，差着十万八千里。
之前见过一个团队，测出来首屏慢，上来就把所有图片都压到WebP，结果老版本安卓机直接白屏——这些机型根本不支持WebP解码，最后紧急回滚，白折腾两周。
工具给的是参考值，不是标准答案。你得先看真实用户的监控数据：有多少用户是在2G弱网下访问的，有多少用户用的是三年前的旧手机，首屏资源的加载阻塞是卡在了JS下载，还是卡在了接口响应，还是浏览器渲染的重排重绘。
真的，每次看到有人把整个React全家桶的依赖全打到首屏包里，我都替用户心疼流量。用户点进来是想买东西，不是来下载三个跟首页半毛钱关系没有的图表库代码的。
那些被高估的优化手段，其实代价大到离谱
很多人把性能优化当成纯赚的买卖，好像只要照着最佳实践做，就能零成本把速度提上去。根本不是那么回事。
前端性能优化从来不是纯赚的买卖，每提一档速度，背后都要算清楚付出的维护成本、兼容成本、基础设施成本。
之前有个做内容站的朋友，咬咬牙上了SSR，首屏加载是快了0.8秒。结果呢？服务器成本直接翻了3倍。原来的静态资源托管一年才花几千块，现在要扛Node服务的并发，动不动就因为某个页面的接口超时把整个服务拖垮，半夜还要爬起来重启服务。
还有人迷信图片懒加载，写个loading=lazy就觉得万事大吉，结果把首屏视口内的图也给设成了懒加载，浏览器要等JS执行完才开始请求这些图，反而多了两次网络往返，速度更慢。
更有甚者，为了省几个请求，把所有CSS都内联到HTML里。要是页面本身HTML就有200k，那每次打开都没法靠强缓存复用这些样式，长期算下来，总加载量反而比单独存CSS文件还大。
麻烦在于，很多人算优化账的时候，只算速度涨了多少，不算后面要填的坑有多大。
真正能落地的优化，都是没人愿意写的笨功夫
那些在技术分享会上被吹上天的优化方案，比如边缘渲染、微前端拆分，听着炫酷，真要落地，没有半年时间根本搞不定。
反而是那些没人愿意花时间抠的细节，改完效果最明显。
比如把首屏的关键CSS抽出来，不要等整个几兆的CSS文件下载完才开始渲染。说起来简单，要从几万行的样式文件里挑出首屏要的那几百行，还不能漏了按钮、卡片的样式，真的要蹲在那逐行核对，没有什么一键工具能帮你完美搞定。
再比如把那些首屏根本用不到的第三方脚本——客服弹窗、行为埋点、广告联盟代码——延后到页面onload之后再加载，别跟主资源抢带宽。之前有个团队，光把客服脚本从head标签里挪到页面最底部，首屏加载就快了1.3秒，连几行业务代码都没改。
说实话，很多团队做性能优化，都是老板拍脑袋说”我们网站太慢了，你给我弄快点”，然后就找几个网上的最佳实践照搬，根本不结合自己的业务场景。比如你一个内部用的后台管理系统，总共也就几百个员工用，你花两周时间做首屏优化，把原来2秒的加载压到1秒，带来的价值还不如把导出Excel的功能做稳定了。
别把跑分当目标，用户真的等不及的那0.5秒，才是值得你花时间优化的部分。
上次跟那个做电商的朋友聊，他说后来他们没再追求什么首屏0.5秒的极致速度。毕竟压到1.1秒之后，再往下每快0.1秒，要付出的代价都是之前的好几倍。现在他们把精力放在了弱网场景下的降级提示上，网不好的时候直接给用户看个简化版的页面，至少不会让用户对着白屏转圈圈。
说白了，前端性能优化从来不是比谁的技术更炫酷，是谁更愿意蹲下来，盯着真实用户的真实使用场景，把那些藏在角落里的小问题一个个抠出来。
这事没什么捷径。