前端首屏加载性能优化 那些没人说透的取舍账

上周跟个做ToB的前端聊，他说上周刚被产品追着骂，后台统计首屏加载要3.2秒，老板拍着桌子说要砍到1.5秒以内，少0.1秒都算不合格。 这事没那么玄。

先搞清楚你要优化的“首屏”到底是什么

很多团队一上来就抄网上的优化攻略，把代码分割、懒加载、资源压缩全套流程走一遍，最后测出来的首屏时间根本没降多少，问题出在最开始的定义就错了。首屏加载的核心判断标准，是用户能看到核心可交互内容的时间，不是浏览器onLoad事件触发的时间。 那个ToB的朋友之前就是踩了这个坑。他之前一直盯着onLoad的时间做优化，把自己写的业务JS压到了300K，结果一测首屏时间还是3秒多，翻了瀑布流才发现，页面里挂的客服聊天SDK、第三方埋点脚本，两个加起来光加载执行就用了1.8秒，刚好卡在渲染阻塞的关键路径上。但用户进这个页面，根本不会第一时间点客服入口，这俩东西占着核心路径挡着渲染，完全是无意义的消耗。

还有更离谱的操作。我之前见过一个营销活动页，首屏还没加载完，先把页面底部的30张用户晒图全部提前加载了，占了快2M的带宽，就因为当初写代码的时候图省事，把所有图片组件扔在同一个父节点里，根本没做视口可见性判断。这种情况下你就算把图片压成WebP，把JS拆的再碎，优化效果也微乎其微——核心问题从一开始就没找对。

那些被吹上天的优化手段，都藏着代价

别迷信什么最佳实践。所有的优化手段都有对应的代价，不存在没有副作用的银弹。 很多人张嘴就说要把所有图片转WebP，要把静态资源全上CDN，要把代码拆成最细的粒度。没错，这些方法单独拿出来都对，但你得算自己的账。WebP格式在三年前的老安卓机型上根本解析不了，要是没做格式降级，用户打开就是一片裂图，体验比加载慢还糟。代码拆分太细也有问题，每个路由单独打个chunk，用户从首页跳到详情页的时候，光JS chunk的请求就要发五六个，HTTP握手的开销直接吃掉了拆分带来的加载收益，最后算下来总时间反而更长。 我之前接触过一个团队，为了把首屏的JS体积压到100K以内，把所有的业务逻辑判断全挪到了客户端运行时做字符串拼接，结果首屏时间是降了0.3秒，但是页面交互的时候卡的要死，用户点个按钮要等半秒才响应，上线一个月留存掉了快两成，这账怎么算都亏。

很多人优化的时候总盯着自己写的代码，却忘了藏在页面里的第三方脚本。第三方脚本的阻塞开销，往往比自己写的业务代码带来的影响更大。一个中型内容站算下来，广告、客服、实时评论这些第三方脚本，平均能占1.2秒的首屏阻塞时间，你把自己写的JS删的只剩骨架，那点优化还抵不上这些脚本拖的后腿。处理方法也简单，别让这些脚本挡着核心内容渲染，要么加async/defer异步加载，要么等核心内容渲染完了再拉取，甚至可以等用户滚动了半屏了，再把客服SDK加载下来，根本不影响功能使用。

别为了0.1秒的指标，把产品搞成四不像

现在好多团队陷在指标焦虑里。老板拍个板，首屏必须压到1秒以内，团队就开始瞎折腾。 我上次见个更绝的团队，为了让首屏时间的统计数据好看，直接把首屏的所有文案、按钮做成了一张静态截图，用户打开页面先看到这张图，等后面的JS加载完了，再把图换成可交互的组件。你说用户傻吗？他点一下图发现点不动，等个两秒突然内容换成能点的了，体验能好才怪。还有的团队为了省几十K的体积，把首屏的产品图片压成模糊的马赛克，连文案都看不清，纯粹是为了指标而优化。 说白了，前端首屏加载性能优化从来不是追求绝对的数值最低，是找平衡。你做的是支付收银台页面，那确实要把加载时间压到最低，毕竟用户等着付钱呢，慢一秒都可能跑单。但你要是做个内容社区的首页，首屏核心的标题、封面图出来了，剩下的内容慢慢加载根本没关系，用户本来就是进来刷内容的，边滚边加载反而更顺。 还有个最容易被忽略的点，别光在自己的开发环境里测性能。本地跑的飞快，不代表三四线城市用着4G网络的用户也能这么快。得把不同网络、不同机型的真实用户数据拉出来看，别拿实验室的最优数据当上线的标准。 上周跟那个被产品追着骂的前端聊，他把三个第三方脚本的加载时机改了，把挡在核心渲染路径上的资源挪了位置，首屏时间直接砍了1.4秒，根本没改几行业务代码。 你看，很多时候优化根本不需要什么高大上的技术。就是别瞎着急。先把挡在用户眼前的东西挪开。