加载条转完了，页面还是不能用

有客户说页面加载完了，点按钮没反应。我去看，加载指示确实结束了。

问题是加载完成不等于可用，首屏可见和可交互，是另外两件事，用户只认这两件。

先把两种慢分开

分开之后，目标才明确，也才知道该给谁提需求。

首屏慢：文字和主图迟迟不出来，用户白屏等着，这时候他已经在考虑关掉了。

整页慢：内容已经能用，页面底部还在持续请求图片和统计脚本，属于拖尾。

两种慢，用户感受完全不同，优化目标也不该一样，混在一起做容易两头不讨好。

五段在首屏上的分布

首屏的时间，是被这五段一段段堆出来的，哪段占得多就该先动哪段。

DNS 和 TCP、TLS：首屏要先解析、先建连，这几段是入场券，省不掉但能压缩。

TTFB：主文档的第一个字，这一段慢，后面所有资源都得排队等。

下载：首屏的关键 CSS、字体、首图，这一段决定视觉什么时候出现。用宝塔拨测的网站测速跑一轮，五段会分开列出来。

优化顺序怎么排

先做看得见的，再做省得多的，用户的感受永远排在报表前面。

先把主文档和关键 CSS 的耗时降下来，这两样决定白屏多久，收益最直接。

首图单独处理，尺寸和格式的收益通常最大，一张大图能顶半个页面。

底部图片、统计脚本可以延后加载，不必挤在首屏关键路径上，让它们晚点来。

用分组看是不是某个地区

范围定不下来，优化就是碰运气，碰对了也只是这一次。

所有节点首屏都慢，问题在服务端和资源，跟节点没关系，加节点是浪费。

只有某些运营商慢，先看链路，加节点比改代码快，也更省人。

复测与动作

改完拿数据说话，别拿感觉说话，感觉在评审会上没有说服力。

改完用同一组节点连测三次，只比首屏相关的段，别被整页数字带跑。

整页的总时间变短但首屏没变，用户依旧会觉得慢，这就是优化了却没人夸的原因。

首屏变快、整页略慢，很多时候是可接受的取舍，关键看用户先要什么。

首屏这条路走顺了，用户才会留下来。

留下来，后面的优化才有意义。

有意义的事，才值得反复做。

反复做，才攒得出经验。

经验多了，判断就快。

快了，就不容易被临时问题困住。

困不住，才能腾出手做长期的事。

长期的事，才是真的优化。

真优化，是把结构理顺，不是修修补补。

理顺了，下一个人接手也轻松。

轻松了，团队才跑得久。

跑得久，才有复利。