首页很快，图片慢

有个图站，首页测速一直很好，用户却说图片要等。我把首页地址反复测了几遍，数字都很漂亮。

后来才想起来，测首页测的是 HTML，图片是另外的请求，甚至可能在另一个域名上。首页快和图片慢，可以同时成立。

图片是独立请求

每张图都有自己的 URL，走自己的 DNS、连接、握手、首字节和下载。

所以判断图片慢，直接拿图片地址去测，别测首页。有了 URL，五段耗时才对应得上。

如果图片在单独的图片域名或 CDN 域名上，那段解析和握手成本会单独算一次。五段里如果 DNS 和 TCP 特别长、图片本身并不大，问题就不在图片，而在域名和连接。

下载段大，先看体积

图片请求的耗时里，下载段占大头是正常的，关键看它大得是否合理。

原图直接输出、没有压缩、尺寸远超展示区域，都会让下载段变长。换成 WebP 或 AVIF、按展示尺寸生成缩略图、开 CDN 缓存，收益通常很直接。

顺手看一眼响应头里的缓存策略。没设长缓存的话，回头客每次都要重新下载一遍。

带宽不够时，所有图片一起变慢，按运营商分组能看到是不是普遍现象。

TTFB 大，问题在后端

如果下载段不长，卡在首字节，那就是服务端在拖。

常见的是实时生成缩略图、图片处理排队，或者每次请求都要鉴权。每次都要回源处理，CDN 也帮不上忙。

尤其注意图片地址有没有带随机参数。带了的话，CDN 每次都当成新资源处理。

这种要从生成逻辑和缓存策略上改，不是把图压小就能解决。

403 和 200 都要看

图片返回 403，可能是防盗链规则拦了，也可能是 WAF 判定异常。表现是图片加载不出来，不是慢。

返回 200 但内容很小，可能是占位图或者错误图。状态码和响应大小一起看，能识别这种情况。

在宝塔拨测的网站测速里对图片 URL 跑多地区多运营商节点，按分组看不同地区是不是都能正常拿到。

域名成本与复测

图片放在独立域名上，好处是并发和缓存隔离，代价是每个新域名都要重新解析、连接、握手。

图片域名多、每张图来自不同域名时，这部分固定成本会叠加。合并域名或者预连接能缓解，但要权衡。

多图页面里，浏览器对同一域名的并发连接也有限，图片太多就会排队。

改完压缩或缓存策略，用同一张图片 URL、同一批节点复测，对比下载段有没有下降。

浏览器侧再看一眼瀑布图，确认图片是不是并发加载、有没有被串行阻塞。两边对上，才算改对了。