图片是站点里最容易被忽视的一类资源。它既占带宽，又影响首屏，还常常是外链和图片搜索流量的入口。很多站点在文字层面已经做了不少整理，图片却一直停留在“能显示就行”的状态：文件名是 IMG_2381.jpg，alt 空着，原图几 MB 直接上传，图床换过一次后留下一批打不开的旧地址。下面整理一次可以自己动手完成的图片与媒体资源自查。
先看体积：一张大图能拖慢整页
把站点体积排名前二十的页面拿出来，逐个看过大的图片资源，通常会有意外收获。常见问题集中在三点：
- 格式没选对。照片类内容用 PNG 会明显偏大，而图标、线条图硬塞进 JPEG 又容易出现毛边。可以按内容类型分别处理，并用 WebP、AVIF 这类更省流量的格式做兜底与回退。
- 压缩过度或不足。压缩过头会出现明显的色块和噪点，压缩不足则几 MB 起步。建议在上传环节固定一个质量档位，而不是每次凭感觉导出。
- 重复上传。同一张图在不同栏目各传一份，改版时只换了其中一处。定期比对资源库里的重复文件，能省下不少存储和缓存空间。
文件名与 alt：给图片一个能被理解的名字
文件名和 alt 文本是图片最基础的两层描述。文件名不用刻意堆词，用简短、带连字符的英文或拼音说明内容即可，避免大批量使用无意义的数字序列。alt 文本要写清楚图片在页面里承担什么信息，装饰性图片可以留空，但正文里的信息图、截图、示意图建议认真填。
顺便检查一下图片周围的上下文：图片如果没有说明文字、也没有相邻段落解释，读者和搜索引擎都很难判断它想表达什么。给重要配图加一句图注，成本很低，效果往往比反复调整 alt 更直接。
尺寸与响应式：别让手机下载桌面尺寸的图
把宽度 1200 像素的图塞进一个 300 像素的卡片位，是最常见的浪费。自查时打开开发者工具，看图片的实际渲染尺寸与下载尺寸是否匹配。现在主流做法是给同一张图准备几档宽度，通过 srcset 让浏览器按屏幕选择，容器本身也要设置好宽高比，避免加载完成后页面大幅跳动。
懒加载：首屏图片不要偷懒
懒加载能显著降低初始请求量，但用错位置会适得其反：首屏主图如果也加了延迟加载，用户会先看到一片空白。一般做法是首屏或首屏附近的图片保持立即加载，其余在视口外的图片再延迟。另外，懒加载最好配好占位尺寸，否则滚动过程中会出现明显的布局抖动。
收录路径：图片也有自己的发现通道
图片资源同样需要可被抓取的地址。自查时关注这几点：图片是否放在允许抓取的目录下，是否通过 robots 规则或防盗链误伤了自己的页面引用；外链图床是否稳定，换图床后老地址是否做了跳转；是否单独提交过图片站点地图。图片站点地图可以集中列出图片地址和所属页面，方便发现，但这只是提供线索，不保证一定出现在图片搜索结果里。
一份可执行的图片自查清单
- 统计页面中体积最大的十张图，确认格式与压缩是否合理。
- 抽查 20 张配图的文件名与 alt，看是否有意义、是否与内容相符。
- 对比图片下载尺寸与页面展示尺寸，补齐多尺寸与宽高比设置。
- 检查首屏图片是否被误加懒加载，占位是否会引起布局抖动。
- 核对图片目录的抓取权限、防盗链规则与 CDN 缓存策略。
- 确认外链图床地址有效，历史替换地址是否做了跳转。
- 整理图片站点地图，剔除已删除或返回错误的图片地址。
图片自查不需要一次做完。按体积排序，先把最重的十张处理掉，通常就能看到加载时间的明显变化；剩下的文件名、alt、站点地图，可以拆成每周固定动作慢慢补齐。