很多站点运营者把注意力放在文字、栏目和收录上，但真正拖慢首屏的，常常是几张没有处理过的图片。图片体积偏大、尺寸超出展示区域、该懒加载的没懒加载，既影响访客体验，也会让蜘蛛在渲染页面时消耗更多资源。这篇自查清单围绕图片展开，不追求把所有图片压到最小，而是找到效果和速度之间的平衡点。
图片为什么容易成为瓶颈
图片同时占用带宽、内存和渲染时间。一张几 MB 的横幅，可能比整页文字加脚本还大。尤其当列表页缩略图、文章配图、产品图都直接上传原图时，页面请求数不一定多，但传输量会迅速上升。对蜘蛛来说，图片过大也会拖慢渲染，影响它对页面主体内容的判断。
- 上传时未压缩，单张图几百 KB 到几 MB。
- 用小图展示却加载了原图，尺寸不匹配。
- 首屏关键图用了懒加载，导致迟迟不显示。
- 图片缺少宽高属性，加载时引发布局跳动。
- 缓存策略不合理，重复访问还在重新下载。
图片体积自查：从格式和尺寸开始
格式选择
不同格式适合不同场景。照片、渐变图通常适合 WebP 或 AVIF 这类现代格式；图标、简单线条图可以用 SVG；需要透明背景且兼容性要求高时，PNG 仍可用，但要注意体积。不要为了统一而把所有图都存成同一种格式，按内容类型选择更实际。
尺寸与压缩
先确认图片在页面上实际显示的最大宽度。如果内容区宽度是 800 像素，上传 3000 像素宽的图通常没有意义，除非用户会点击放大。压缩时优先使用有损压缩工具，在肉眼可接受范围内降低质量。对于需要透明度的图，可以尝试调色板压缩或改用 WebP。
- 列表页缩略图单独生成小尺寸版本，不要直接调用原图。
- 为图片设置明确的宽度和高度，减少布局偏移。
- 检查是否有重复上传的相似图片，合并或删除旧文件。
- 图片文件名和 alt 文本尽量描述内容，不要堆砌关键词。
懒加载自查：不是所有图片都该延迟
懒加载的本意是推迟屏幕外图片的加载，减少初始请求。但如果把首屏可见图片也设成懒加载，浏览器可能要等脚本执行后才开始下载，反而拖慢最大内容绘制。自查时，先找出首屏区域内的关键图片，确认它们没有被延迟加载。
- 首屏主图、Logo、文章头图建议正常加载。
- 屏幕外的长列表图片、页脚图片可以懒加载。
- 懒加载要提供占位尺寸，避免滚动时页面跳动。
- 如果使用 JavaScript 懒加载，确认蜘蛛能获取到图片地址，而不是只看到占位图。
提醒：懒加载不是越多越好。关键图片延迟加载，可能让访客和蜘蛛都以为页面是空的。
响应式图片与缓存检查
响应式图片的目标是按设备宽度提供合适尺寸。常见做法是准备多个尺寸版本，让浏览器根据视口和像素密度选择。自查时，可以抽查手机端是否加载了桌面端大图。如果只有一张大图，移动端用户就会承担不必要的流量。
缓存方面，给图片设置较长的缓存时间，并通过文件名或版本参数在更新后失效。检查 CDN 是否缓存了旧图，更新后是否及时刷新。若发现访客仍看到旧图，先确认源站文件已替换，再检查 CDN 缓存和浏览器缓存。
图片与蜘蛛抓取：别忽略可访问性
蜘蛛渲染页面时，图片也是页面的一部分。图片地址如果被 robots.txt 挡住，或者依赖复杂脚本才插入，可能影响蜘蛛对内容的理解。但也不需要为了蜘蛛单独做一套图片，保持正常的 HTML 图片引用和可读的 alt 文本即可。
- 重要图片使用标准 img 标签，而不是纯背景图。
- alt 文本描述图片内容，装饰性图片可以用空 alt。
- 避免用图片代替大段文字，尤其是标题和正文。
- 检查图片是否返回 200 状态，不要出现大量 404 图片。
一份可执行的自查流程
- 打开几个代表性页面，用浏览器开发者工具查看网络请求，按体积排序。
- 找出最大的几张图片，确认它们是否在首屏、是否用了正确尺寸。
- 检查首屏图片有没有被懒加载，宽高属性是否完整。
- 抽查移动端加载的图片版本，是否比桌面端明显偏大。
- 确认图片缓存头和 CDN 刷新策略，更新后是否生效。
- 检查图片 alt 文本、状态码和是否被 robots.txt 误挡。
图片优化不需要一次做完。每次更新页面时顺手处理几张，逐步替换旧图，比集中折腾更可持续。把图片体积、懒加载边界和缓存策略纳入日常自查，页面会更轻，蜘蛛抓取和渲染也会更顺畅。