很多站点在内容上下了不少功夫，图片却一直按最初上传的样子躺在服务器里。时间一长，同一个页面里既有几十 KB 的缩略图，也有两三 MB 的原图直出，alt 文本要么空白要么写着“图片1”。这类问题不会立刻让站点出故障，但会持续影响访客的打开体验，也让图片这类资源在抓取和收录环节处于被动状态。
为什么图片值得单独做一次自查
文字内容通常有编辑流程把关，图片却常常是“传上去就算完成”。它涉及的环节其实不少：文件本身的大小和格式、在页面中出现的上下文、是否带有说明文字、是否被正确引用。任何一个环节出问题，表现都是沉默的——页面照样能打开，只是慢一点、少一点信息。
一、文件体积与格式
- 检查列表页和文章页的首屏图片，看是否存在直接引用原图的情况。同一张图在缩略图和详情页往往需要不同尺寸。
- 照片类内容优先考虑压缩率较好的格式，图标、纯色块、简单插画可以考虑矢量或更轻的格式。
- 注意是否有多余的元数据留在文件里，例如相机信息、设计软件图层数据。导出前清理一次，通常能省下可观体积。
- 批量压缩后要抽查画质，尤其是带文字、带细线条的图片，压缩过度会出现明显噪点。
二、文件名与 alt 文本
文件名和 alt 文本是图片少有的“可读信息”。文件名建议用简短、有含义的英文或拼音，用连字符分隔，避免一串无意义的编号。alt 文本的作用是在图片无法显示时说明内容，同时为读屏软件提供信息，写法上描述画面本身即可，不必堆砌关键词，也不要写成一段广告语。
- 纯装饰性图片，alt 留空是合理的，不必强行填写。
- 带文字的图片，可以把文字内容概括进 alt，方便无法查看图片的访客。
- 同一页面里多张图片的 alt 尽量不要完全重复。
三、尺寸属性与布局稳定
图片如果没有声明宽高，浏览器在图片加载完成前不知道要预留多少空间，页面内容会被挤动一下。这在移动端尤其明显，访客可能正要点某个按钮，位置却突然变了。给图片标签补上宽高属性，或者用样式预留比例，是很低成本的一项改动。
四、懒加载与首屏图片
懒加载适合页面下方那些一开始看不到的图片，能减少首次加载的压力。但首屏图片不建议延迟加载，否则访客会先看到空白再看到主图。这里常见的误区是给全站图片统一加同一个懒加载属性，结果是首屏也被拖慢。可以按位置区分处理：首屏直接加载，其余按下滚动触发。
五、失效图片与历史残留
内容改版、栏目调整、服务器迁移之后，经常留下一些地址已经失效的图片引用。它们表现为破图占位，或者一个持续请求失败的空地址。建议定期做这几步：
- 抽取页面中的图片地址，逐条请求一次，记录返回异常的条目。
- 确认是路径写错、文件被删，还是域名更换后没有同步更新。
- 能修复的修复，确定不再使用的图片从页面中移除，而不是留一个空标签。
- 删除文件前先确认没有其他页面引用，避免制造新的失效图。
六、把图片纳入日常维护节奏
自查不必一次做完，可以固定成一个小流程：新内容发布前检查体积、文件名和 alt；每月抽查一批老页面的图片状况；每次改版前，先拉一份图片引用清单。这样做的收益不会立刻体现在某个数字上，但访客的等待时间、页面的整体重量会慢慢变得可控。
图片是页面里最容易被忽略、又最容易累积问题的部分。把它当成内容的一部分来管理，比事后再做一次集中清理要轻松得多。
一份简化版自查清单
- 页面里是否有未经压缩的大图直接输出？
- 图片文件名和 alt 文本是否能说明内容？
- 是否声明了宽高或预留了显示比例？
- 首屏图片是否被误加了懒加载？
- 是否存在破图、空地址或已被删除的文件引用？
- 历史文章中的图片是否也能正常显示？