首屏图出来一半就停住

客户说首页加载慢，我打开一看，文字早出来了，图片是一块一块往下掉。

只测首页得到的结论是「整体有点慢」，可这个结论对修图片没有任何帮助，方向都不对。

先测图片地址本身

测对了对象，结论才有用，测错了对象只是在浪费节点额度。

首页是一个混合体：HTML、CSS、脚本、图片、字体都挤在一次加载里，谁慢都被算在一起。

要判断图片慢，就得拿图片的 URL 单独测一次，这是唯一能把变量分开的办法。

这样得到的数字才只属于图片，不会被其他资源稀释，也才敢拿去和同事对。

五段在图片上的含义

同一套五段，在图片上侧重点不一样，别拿网页的经验直接套。

DNS：图片常放在独立域名或图床，解析慢会拖住整批图片，一张都别想快。

TCP 和 TLS：图片域名单独建连、单独握手，图片越多，这部分开销越显眼，几十张图就是几十次握手。

TTFB：这一段慢，说明请求到了图床，回源、鉴权、或者防盗链校验在等。

下载：这一段慢，说明文件和链路的问题，体积越大越明显。用宝塔拨测的网站测速直接测图片地址，五段会分开列出来。

三个放大器

这三个会把小问题放大成用户能看见的卡，而且互相叠加。

体积和格式：同样一张图，格式不同可能差好几倍，尺寸超配更是常见问题。

并发：几十张图同时请求，浏览器排队，单张再快也白搭，用户看到的还是慢慢出来。

缓存命中：命中缓存几乎没有下载段，没命中就要重新走一遍全流程，差别非常直观。

用分组看是图床还是链路

范围决定改哪一边，也决定这笔钱花得值不值。

所有地区都慢，问题在图床或源文件，改链路没有意义。

只有某几家运营商慢，是链路，换图床未必有用，先确认范围再动手。

复测与动作

改完能验证，优化才算完成，否则只是换了个说法。

同一张图连测三次，确认是稳定慢还是偶发，偶发的先记着观察。

改格式或压缩后再测，只比下载段，别把建连时间算成优化，那样数字会骗人。

图片多的时候，优先处理首屏那几张，其余的收益要算一算，不是每张都值得优化。

图片慢这件事，测对一张图，比测十次首页有用。

测对了，判断也就有了落点。

有落点，改动就不会四处乱撞。

不乱撞，才谈得上效率。

效率上来了，工期就稳了。

稳了，后面就不必天天救火。

不救火，才抽得出时间优化。

时间用在优化上，收益才滚得起来。