都在说卡，说的不是一件事

客服转过来三条反馈：一条说打开半天白屏，一条说点了没反应，一条说滚动的时候一顿一顿。

这三条我都按「卡」处理过，结果前两条是网络和接口，第三条根本不是服务器的事，白折腾了半天。

第一种：首屏卡

这一种最容易误判成服务器慢，实际可能连请求都没发出去。

现象是地址敲进去，页面迟迟不出来，或者只出来一个骨架屏，内容一直在等。

对应的是 DNS、TCP、TLS 和下载这几段，请求还没走到内容渲染，报错也多半在这一段之前。

这种情况下改后端逻辑没用，因为请求可能还没到后端，改了也测不出变化。

第二种：点击卡

这一种最容易和接口问题混在一起，看页面耗时永远是错的。

页面已经在了，点一个按钮，转圈几秒才有反应，用户会以为没点上，于是连点三次。

这一段对应 TTFB，也就是服务端处理时间，接口、数据库、第三方调用都算在里面。

如果按钮触发的是异步请求，还要单独看接口自身的耗时，页面耗时这时候没有参考价值。

第三种：滚动卡

这一种最容易冤枉服务器，换十台机器也不会变快。

内容都加载完了，滚动、切标签、展开列表时掉帧，鼠标一顿一顿的。

这时网络基本没关系，压力在本机的脚本执行和渲染，加带宽不会变顺。

用宝塔拨测的网站测速测一次，如果五段耗时都正常、状态码 200，而用户依旧觉得卡，方向就该转向页面本身，别再纠结服务器配置。

用分组把范围定下来

范围定下来，改动才不会撒胡椒面，钱也不会白花。

只有某些地区卡，先看链路和运营商，别急着改代码，改了别人也感受不到。

所有地区都卡在同一种操作上，问题更像共性的，比如接口、某个组件、某段脚本。

按运营商分组、看平均和最慢节点的差距，能把「局部」和「全局」分开，也能少吵几轮。

复测才算闭环

能复现、能对比，优化才站得住，也才敢写进周报。

改完用同一组节点、同一时段测，只比同一段耗时，条件变一个结论就不成立。

连续测三次，稳定改善才算真的改善，一次好结果可能只是刚好不堵。

页面侧的优化，最好同时记录操作路径，不然下次连现象都复现不了。

三种卡分开看，解决路径就清楚多了。

清楚之后，就不必所有手段一起上。

手段少一点，效果反而更明显。

明显了，用户才真的觉得不卡。

用户感受，才是最后的验收标准。

标准对了，优化就不会跑偏。