一打开就假死

客户说页面一打开就卡死，鼠标都要等两秒才动，换浏览器也没用。

这种程度的卡，已经不像「慢」，更像本机被压住了，光看耗时数字反而看不出问题。

先做两个排除

排除了，方向才会收窄，也才有底气跟客户说下一步。

换一台配置正常的设备打开，看是不是同样卡，这一步最便宜。

再用不同的网络试一次，排除带宽和链路，两分钟不用。

两样都做完，你就知道该往哪边查，而不是原地猜，也不至于被一句「我这边正常」堵住。

测速给一个客观参照

有数字，才好跟别人对齐，不然双方只能各说各的感受。

用宝塔拨测的网站测速跑多地区多运营商节点，重点看 DNS、TCP、TLS、TTFB、下载五段耗时。

五段正常、状态码 200，说明网络和服务端这一侧是无辜的，继续查它们只会浪费时间。

下载段特别大，说明资源体积可能已经超过设备的处理能力，尤其是低配电脑和老手机。

本机被压死的三种机制

听起来玄，其实都能测出来，浏览器自带的面板就够用。

DOM 太多：一屏塞几千个节点，布局和重绘就够呛，滚动的时候最明显。

长任务：一段脚本跑几百毫秒，主线程被占住，点击自然没反应，用户以为按钮坏了。

内存持续增长：页面开着不关，内存一直涨，最后触顶开始卡，刷新一下又好了。

优化顺序

先动影响交互的，再动影响体积的，用户先能点得动才谈得上好看。

先砍可见区域外的渲染，该懒加载的懒加载，别一次全画出来。

再拆长任务，把大段计算切成小块，让浏览器有机会响应用户操作。

最后处理资源体积，图片和脚本都要过一遍，收益往往比你想象的大。

复测与验证

用户那边通过，才算通过，自己机器上流畅没有意义。

改完换回原来那台设备，用同样的操作路径再试一次，这比在开发机上验证可靠。

同一组节点再测一次，确认网络侧没有变化，只是页面变轻了，这样结论才干净。

只有用户点下去有反应，才算真的解决，指标好看但交互仍然卡，等于没修。

特别卡这类问题，先排除，再优化，顺序不能反。

反了，就容易在无辜的地方使劲。

使劲用对了地方，效果才看得出来。

看得出来，就可以停手了。

停手，也是一种能力。

能力到位，判断也就稳了。

稳了，客户才会继续找你。

找你的人多了，经验自然就厚。

经验厚了，判断会更快。

快了，就不用熬那么多夜。

少熬夜，状态也会好很多。