## 症状现象
页面文字秒开，图片转圈好几秒，高峰期更明显。带宽监控没有跑满，服务器 CPU 也闲着，慢在哪儿说不清。图片慢的归因先分两条线：传输慢与取图慢，前者是带宽与线路问题，后者是存储读取慢，处理方向完全不同。
## 定位过程
用带计时的请求把一次图片加载拆开：域名解析、连接、首字节、总下载四段耗时。首字节时间长、下载段短，说明慢在取图：请求到了服务器，等存储把文件读出来就耗掉大头，存储 IO 是瓶颈；首字节快、下载段长，说明慢在传输：单位时间送达的数据量不足，带宽或线路是瓶颈。高峰更慢且多条链路一致，偏向存储线；分地区差异大，偏向线路线。
curl -o /dev/null -s -w "dns:%{time_namelookup} conn:%{time_connect} \
ttfb:%{time_starttransfer} total:%{time_total} size:%{size_download}\n" \
example.com/static/big.jpg
顺云控制台的带宽图表与磁盘 IO 图表并排对照，两条线哪条在请求时段爬坡，答案就偏向哪边。
## 解决方法
传输线：压缩图片体积、启用浏览器缓存、接入 CDN 类分发把图片推近用户、必要时扩带宽。存储线：原图与缩略图分层，原图放对象存储类服务，页面只取缩略图；本机盘的换更快的盘或加读缓存。多数站点两条线都要做，先做收益大的那条。
## 预防建议
图片类站点上线前就规划好缩略图流水线与外置存储，图片与页面不同生命周期，混在一起最后总是图片先拖垮服务器。带宽与存储水位告警都配齐，慢的问题让数据先说话。
长期治理的方向再明确一下：图片是静态资产的典型代表，治理思路是让图片离用户越来越近、离应用服务器越来越远。格式与尺寸的规范化是第一收益，统一转新格式与预设尺寸，体积普降；懒加载让首屏之外的内容不再抢首屏的带宽。这两项做完，多数站点的图片类延迟问题可以消退大半，剩下的长尾再交给分发层。经验上，图片类优化的投入产出比高于任何服务器升配。