很多站点运营的精力都花在标题、栏目和更新节奏上，图片往往被当成“顺手传上去就行”的素材。等到页面越做越长、媒体库越堆越大，才发现打开速度、抓取效率和移动端体验都被它悄悄拉低了。
图片为什么容易成为短板
图片是页面上最占体积的资源。一张未经压缩的手机原图可能有两三 MB，一个列表页放十几张，访客就要多等好几秒。对搜索引擎来说，图片同样是需要抓取的内容，体积大、数量多、还频繁变动，都会持续占用抓取资源。更麻烦的是，很多图片问题从后台看不出来，只有在前台加载和日志里才露馅。
图片自查的几个重点
文件体积与格式
- 导出时是否按展示尺寸压缩，而不是把 4000px 的图缩显成 400px；
- 照片类内容是否优先使用 WebP、AVIF 等现代格式，并保留必要时的兼容回退；
- PNG 是否只留给需要透明或线条图的位置，避免拿它存大照片。
尺寸标注与响应式
- img 标签是否写明宽高，避免加载时页面内容跳动；
- 是否用 srcset、sizes 给不同屏幕准备合适尺寸，而不是一套大图打天下；
- 列表页缩略图与详情页大图是否共用同一份原图，能不能拆开。
懒加载与首屏
懒加载能省流量，但用错位置反而更慢。首屏主图、Logo、导航图标这类马上可见的图片不要加懒加载，否则要等脚本执行才发出请求，视觉上会先空一块。正文中部和底部的图片、图集里未展开的图片，更适合按需加载。
文件名、alt 与上下文
- 文件名是否有意义，例如 server-room-rack.jpg 而不是 IMG_2043.jpg；
- alt 是否描述图片内容，而不是堆关键词，纯装饰图可以留空；
- 图片旁边的文字是否说明了它是什么，如果图片单独承载关键信息，最好在正文里补一句文字。
图片能否被正常访问
常见问题包括：图片服务被防盗链规则挡住，抓取请求拿到 403；图片目录在 robots 里被误封；图片走 CDN 但回源地址写错，日志里一片 404。建议定期抽查图片地址的返回状态，确认是正常的 200，而不是靠登录态、Referer 过滤或脚本执行才显示出来。
一次简单的图片盘点流程
- 从访问日志或图片服务日志里导出被请求最多的图片地址，按体积排序；
- 挑出体积最大的若干张，逐一确认展示尺寸和格式是否合理；
- 在移动网络环境下打开几个主要模板页，记录首屏内容出现的时间；
- 用无痕窗口、并去掉 Referer 的方式请求图片，看是否仍能正常返回；
- 清理媒体库里没有被任何页面引用的历史文件，或至少做好归档记录；
- 把压缩和命名规范写进编辑流程，新图上传前先过一遍。
几个常见误区
- 压缩就等于糊：合理压缩和明显失真之间还有空间，多试几档质量再定标准；
- 只盯首页：栏目页、文章页、图集页的图片体量往往更大；
- 水印越重越好：大面积水印既影响观感，也让图片本身更难被识别；
- 换格式就万事大吉：格式只是一环，尺寸、数量和加载时机同样重要。
图片优化的目标不是把每张图都压到最小，而是让访客尽快看到该看的内容，同时不给抓取留一堆无意义的负担。
图片问题通常不会一次爆发，而是随着内容累积慢慢显现。把体积、尺寸、加载方式和可访问性做成固定检查项，比起出问题后再回头翻媒体库要省力得多。