还是慢。
他挠头问，是不是要上SSR？我拉着他的Chrome DevTools跑了一遍Performance。
哦。
他的首屏白屏，根本不是资源加载慢。
是HTML文档本身，在服务器端生成要花1.7秒——他把首屏要展示的30条内容，全在Node服务里同步查了三次数据库，还在同一个接口里拉了广告位配置。
先搞懂你测的慢到底是哪一段慢
很多人嘴里的“首屏慢”，根本是个模糊的概念。
有人说的慢是白屏久——就是用户点进来，等了半天啥都没有，连个背景色都不出来。有人说的慢是内容出来了但点不动——按钮按了没反应，链接跳不了。
你得把整个加载链路拆成碎段看。从用户输入网址那一刻开始，DNS解析、TCP握手、TTFB（服务器返回第一个字节的时间）、HTML下载解析、CSS加载、DOM树构建、首屏内容渲染、JS加载执行、事件绑定，每一段的耗时都要拎出来。
刚才那个朋友的情况，TTFB就占了1.7秒，后面所有资源加起来的加载耗时才0.4秒。他之前折腾的压缩图片、拆包、缓存，全是在那0.4秒里挤水，当然看不到明显效果。
这事真的太常见了。我见过至少一半的团队，做前端首屏加载性能优化的时候，连自己的TTFB是多少都没测过，就先把webpack的拆包插件装了。
别迷信通用优化清单
网上流传的优化清单，每条单独拿出来都没错，但套到你的站身上，未必有用。
比如图片懒加载。大家都喊要做，可如果你首屏本来就要展示3张图，你给这三张图也加了懒加载监听，反而要等JS初始化完、监听到可视区域之后才开始加载，平白多了几十毫秒的延迟。
还有JS拆包。很多人照着教程把vendor拆成好几个chunk，结果首屏要请求七八个小JS文件。如果你的用户大多在三四线城市，用3G网络，并行请求的开销反而比单个大JS更大——请求多了，握手的时间就多了。
之前接触过一个做本地生活的团队，他们一开始把所有第三方SDK都塞在head里，什么统计、客服、广告，光这些JS就占了首屏可交互时间的40%。后来他们把这些SDK全改成用户第一次滚动或者点击之后再加载，首屏可交互时间直接砍了一半。
最烦的是那些SDK厂商的文档，全写着”请放在head标签内保证统计准确性”，说白了就是不想做延迟加载，把成本甩给你的站点。
优化的代价你得提前算清楚
很多人觉得优化是免费的，其实每一个方案都有代价。
比如SSR，确实能把TTFB降下来，首屏出来的速度快。但你得维护一套同构代码，还要给服务器加渲染资源，原来的静态站改成SSR之后，服务器成本可能涨两三倍。如果你的站本来就是内容更新不频繁的，完全可以用预渲染，把首屏的HTML提前生成好存在CDN上，成本比SSR低太多了，效果差不多。
还有图片用WebP，压缩率比JPG高30%，加载更快。但你得考虑老版本的安卓机能不能兼容，得做格式降级，不然用户打开全是裂图，得不偿失。
缓存也是个坑。很多人给带hash的JS和CSS设了一年的强缓存，这没问题。但有人顺手把入口HTML也设了强缓存，结果改了版本之后，用户还是加载旧的文件，出了线上bug，还要紧急回滚。说白了，缓存的粒度要卡好，带hash的静态资源可以放心强缓存，入口的HTML一定要设no-cache，不然全白搭。
很多人觉得前端首屏加载性能优化是个纯技术活，其实到最后都是算账的事——你要多少性能，愿意花多少成本，愿意承担多少兼容性风险，没有万能的方案。
上周那个朋友后来把服务器端的同步查询改成了并行查库，把广告位配置挪到了客户端异步加载，TTFB直接降到了300毫秒。现在首屏1.2秒就能出来。
他说早知道先测瓶颈，就不用折腾那一周了。