图文站点的内容里，图片占比往往比想象中高，但它也是最容易被放过去的一环。正文改了三版，配图还是当年从素材站随手下载的那张。图片不出问题时没人注意，一旦出问题，表现通常是首屏变慢、移动端流量白跑、图片搜索里找不到入口。下面把图片相关的自查点整理成一份可以按季度过一遍的清单。
一、体积：先看能省下来的那一半
图片体积是最直接的成本，也是最容易拿到收益的地方。很多站点的首屏慢，不是因为代码复杂，而是因为一张没压过的头图。
- 照片类图片存成了 PNG，体积常常是 JPEG 的三到五倍；
- 单张配图超过 500KB，滚动到该位置时明显卡一下；
- 列表缩略图直接用原图裁切，展示尺寸 200px，实际下载 2000px；
- 同一张图在文章页、栏目页、专题页各上传一份，互不复用。
处理方式不复杂：先跑一遍站点图片的批量盘点，按体积排序，把排名靠前的几十张重新导出。压缩时保留一个可回溯的原图目录，避免以后想换尺寸时只剩压缩版。
二、格式与压缩：别只盯着一种格式
WebP 现在的兼容性已经够用，AVIF 在部分场景下更小但编码更慢。实务上可以这样分工：保留 JPEG 作为兜底，用 picture 或 accept 协商的方式给支持新格式的浏览器提供 WebP。压缩质量不必追求极限，照片类 75 到 82 之间通常肉眼差异不明显，再往下压容易出现块状噪点，反而显得站点粗糙。
三、尺寸与响应式：别用大图缩小显示
用 CSS 把 1600px 宽的图缩到 320px 显示，省的是排版，不是带宽。列表页尤其容易出现这种浪费。可以给主要图片模板加上 srcset 和 sizes，让浏览器按视口和像素密度自己挑合适的版本。至少准备两档：一档给列表和缩略图，一档给正文大图。
判断标准很简单：打开开发者工具的 Network 面板，看实际下载的图片尺寸和你眼睛看到的尺寸差几倍。差三倍以上就值得改。
四、alt 与文件名：给机器留一点线索
alt 文本的第一作用是给读屏软件和图片加载失败时看，第二作用才是给搜索引擎。写得自然、描述画面内容即可，不要堆关键词，也不要把 alt 留空后指望周围的正文自动补位。
文件名同样如此。IMG_2043.jpg 换成能说明内容的英文或拼音短语，成本几乎为零。真正需要避免的是把同一段关键词复制到十几张图上，那属于明显的堆砌。
五、懒加载：首屏是例外
懒加载几乎已经是标配，但常见的错误是把首屏大图也一起懒加载，结果浏览器要等布局计算完才去请求，首屏反而更慢。做法是首屏第一张图用 eager 加载，必要时加 fetchpriority 提示；首屏以下的图片再交给懒加载。同时给图片写死宽高或宽高比，避免加载过程中页面反复跳动。
六、图片与抓取：不占索引，但影响渲染
图片本身并不直接占用正文索引位置，但它会占用渲染资源。如果页面依赖大量图片才能撑出正文高度，蜘蛛在渲染阶段就可能拿到一个不完整的页面。另外，图片所在路径如果被 robots.txt 挡住，图片搜索的入口也就一并没了，这一点在做全站屏蔽时经常被顺手连坐。
七、可以照着做的自查清单
- 按体积排序，列出全站最大的 50 张图片；
- 检查照片类图片是否误用 PNG；
- 检查缩略图是否直接引用原图；
- 确认正文大图模板已配置 srcset；
- 抽查 20 张图片的 alt，看是否为空或堆砌；
- 检查首屏首图是否被错误地设为懒加载；
- 确认图片目录没有被 robots.txt 误挡；
- 在移动网络模式下打开三个代表性页面，记录首屏时间。
这份清单不需要一次做完，挑体积最大的那批先处理，往往就能看到明显变化。剩下的作为常规维护项，跟着内容更新节奏顺手过一遍即可。