前端首屏慢，我按这四步往下查
打开页面，空白停了大概两秒才出内容。这种时候最容易犯的错是凭感觉猜原因，然后改一个地方，发现没用。前端首屏加载慢怎么一步步排查，我的做法是固定四步，按顺序走，不跳步。
顺序不能换。先证明到底慢不慢，再确定慢在哪一段，然后才动手。
前提：前端首屏加载慢怎么一步步排查，先排除不是你代码的问题
动手之前先确认一次网络和服务端响应。如果服务器返回本身就慢，前端怎么改都没用。
判断方法很简单：看请求什么时候开始有响应。响应迟迟不来，问题在服务端；响应很快但页面还是白，那才轮到前端。
第一步：把「慢」定成一个可比较的数
先给现在的状态记一个数，比如从打开到看见主要内容用了多久。
这一步的意义是让后面的每一次改动都有参照。没有基线，你就无法判断自己是改好了还是改坏了。记的时候用同一台设备、同一种网络，别每次条件都不一样。
第二步：确认时间花在哪一段
把过程拆成三段看：请求发出到服务器响应、资源下载、下载完之后到看见内容。
三段里通常只有一段是大头。找出这一段，后面的动作才有方向。如果三段看着都不大但总体就是慢，那多半是资源太多太碎，属于拆包问题。
第三步：按这一段的特征对症下手
如果是响应慢，先看服务端；如果是下载慢，看总体积和请求数量；如果下载完还白屏，大概率是渲染被同步逻辑挡住了，比如初始化时跑了很重的计算。
一次只改一个地方，改完再量一次。同时改三处，就算变快了也不知道是哪一处起的作用，下次还会踩。
第四步：给这次改动加一道防线
改好之后，把这次的数值记进项目里，写在能看见的地方。
原因是我自己吃过亏：优化完过一段时间，新加的功能又把它拖回去了，而且没人发现。留下一个对照数值，下次回归时至少有个参照。
容易卡住的两个点
第一个卡点是本地测得好好的，线上还是慢。这通常是测试条件不一致造成的，本地网络比用户好、开发机比用户设备强。把条件调差再测一次。
第二个卡点是一直在优化，但用户没感觉。这时候要停下来问一句：用户真的在意这一段吗。首屏白屏用户会在意，后台管理页慢半秒没人在意。
把四步记成一句话就是：先证明慢，再定位段，然后只改一处，最后留个参照。
这个顺序的价值在于它防住了一个很常见的循环——猜一个原因、改一下、感觉快了点、过两天发现没有、再猜下一个。这个循环能跑很久，因为它每次都有「好像有效果」的反馈。
加了基线和单次改动之后，这个循环就跑不起来了：数值没动就是没动，赖不掉。我自己复盘过，之前浪费的时间基本都在这个循环里，而不在真正的技术难点上。
还有一句关于心态的：首屏慢最容易的失误，是把它当成一个必须解决的问题。实际上有些慢可以接受，一年访问两次的后台页，慢一点没人在意。
我的判断标准是看这个页面的访问量和它承担的任务。首页、主要路径要认真对待，角落里的页面让它慢着。把所有页面都优化一遍，是一种看起来很勤奋的浪费。
前端首屏加载慢怎么一步步排查，四步走完就够了，别让排查本身变成新的消耗。
常见问题
Q：前端首屏加载慢怎么一步步排查，第一步做什么？
A：先记一个基线数值，用固定的设备和网络测一次。有了基线，后面每一步改动才有对比依据，否则容易越改越乱。
Q：首屏慢一定是前端的问题吗？
A：不一定。服务端响应慢会让首屏一样慢，所以排查前先确认响应时间，把这个可能性排掉再看前端。
Q：优化完怎么防止变回去？
A：把这次的测量数值记录在项目里，作为后续改动的参照。新功能上线后重测一次，发现回落就能及时定位。
相关阅读
本文作者西米，37 岁程序员，一个人加五个 AI 员工在跑一家公司。踩过的坑和真实账本都写在公众号「西米分享」。
完整代码、踩坑清单与最新进展，都在公众号。
📱 关注公众号「西米分享」