一秒多，可白屏四秒

客户发来一条测速结果，总耗时一点二秒，问我为什么他打开要等四秒。

我一开始也怀疑他记错了，后来自己清缓存打开，确实等了好几秒，才发现我们说的是两件事。

两个时间算的不是一件事

分开看，才不会互相否定，也才知道该改哪边。

测速的总耗时，是从发起请求到最后一个字节接收完，包含所有资源的收尾。

用户感知的白屏，是到首屏出现可见内容为止，后面加载什么都不影响他的第一印象。

这两个时间之间，隔着脚本执行、样式计算、字体加载和首次渲染，全是浏览器干的活。

从结果里能推什么

测速不能直接测白屏，但能给出线索，够用来排除一半可能。

TTFB 很长，白屏一定会跟着长，因为主文档都没回来，浏览器无从开始。

TTFB 正常，但下载段里有几个大资源，关键资源晚到也会拖住首屏，哪怕总耗时很好看。

状态码 200 也不能说明没问题，返回空体照样白，这个坑踩过不止一次。

用宝塔拨测的网站测速跑多地区多运营商节点，五段和状态码一起看，能先排除传输层的白屏原因，剩下的再往渲染找。

白屏往往卡在关键路径

这一段占白屏时间的大头，改它收益也最大。

同步脚本放在头部，会阻塞渲染，白屏时间直接加倍，这是最常见的一处。

关键 CSS 太大或者要额外请求，样式没到就什么都不显示，用户只能盯着白屏。

字体文件缺失，文字会先不可见，看起来像白屏，其实内容早就下载完了。

怎么实测白屏

工具给不了，就自己量，两分钟的事。

换一个干净环境，清缓存，从头打开一次，用秒表大致计时，别太精确反而够用。

看屏幕第一次出现内容是在几秒，记下来，这就是用户真实感受的那个数。

再看这个时间点和网络面板里哪个资源完成时间接近，那个资源就是头号嫌疑。

优化顺序与复测

先处理阻塞渲染的脚本和样式，收益最直接。

再处理首屏图片和字体，尺寸和格式一起看。

非关键资源全部延后，别和首屏抢带宽。

改完用同一组节点复测，同时自己再清缓存打开一次。

两个数都改善，才算真的不白屏，只改一边很容易自嗨。

只改一项就宣布解决，很容易被下一次投诉打回来，也浪费一次信任。

白屏这件事，数字和眼睛都得用上。

用上，判断就不会只停在报表。

停在报表，优化就会跑偏。

不跑偏，改完才见效。

见效了，用户就不再说白屏。

不说白屏，才叫真的解决。