图片和静态资源为什么值得单独查一遍
很多站点运营把注意力放在页面和链接上，图片、CSS、JS、字体这些静态资源却很少被翻出来看一遍。它们不直接决定页面能不能被收录，但会实实在在影响加载速度、渲染完成时间，也会占用服务器的请求数和带宽。当站点的抓取请求额度有限时，把额度花在几百张没压缩的大图和一堆已经失效的文件上，显然不划算。
这类问题的麻烦之处在于它不会报错，页面看上去一切正常，只有打开开发者工具或者翻日志才会发现异常。所以更适合按固定清单定期过一遍，而不是等出问题再查。
第一步：把页面实际加载的资源列出来
不要凭记忆列清单，要以真实加载结果为准。常用做法有三种：
- 用浏览器开发者工具的 Network 面板，勾选 Disable cache 后刷新，查看全部请求；
- 用站点爬虫工具抓一遍全站，筛出图片、样式、脚本、字体这几类资源；
- 翻服务器访问日志，按文件后缀统计请求量和状态码分布。
三种方式视角不同：开发者工具看的是单个页面的真实加载，爬虫看的是全站覆盖，日志看的是实际被请求最多的那些文件。三者对照，问题基本藏不住。
第二步：先把失效资源清掉
这一步优先级最高，因为它是纯损耗。重点看两类：
返回 404 或 403 的资源
常见来源是改版时删掉的图片目录、被替换掉的旧样式文件、写错路径的引用，以及外链图床失效。图片缺失时页面不会报错，只会留一块空白，用户和蜘蛛都看不到那里的内容。
长期超时或跨域加载失败的资源
如果页面上引用了第三方 CDN 的脚本或字体，而对方响应很慢甚至偶尔失败，页面渲染就会被拖住。可以定期核对一次外部资源的可用性和响应时间，把不必要的依赖去掉。
判断标准很简单：这个文件如果加载失败，页面内容还能不能完整看到？答案是否，就该优先处理。
第三步：核对体积、尺寸与格式
尺寸是否和展示位置匹配
把 2000 像素宽的图缩到 300 像素的缩略图位置展示，是最常见的浪费。上传前先按实际展示宽度裁剪，而不是交给 CSS 缩放。
格式是否合适
- 照片、插画类内容：优先用 WebP 等现代格式，保留 JPEG 作为兜底；
- 图标、简单图形：用 SVG，通常比位图小很多且缩放不模糊；
- 截图、带文字的图：注意压缩后文字是否还清晰，不要一味追求最小体积。
压缩是否做到位
用批量压缩工具走一遍，通常能砍掉不少体积，且肉眼几乎看不出差别。注意保留原图备份，方便以后重新导出不同尺寸的版本。
第四步：首屏资源与懒加载
懒加载本身没问题，但用错位置会带来副作用。如果首屏大图也设了懒加载，用户打开页面时可能要等脚本执行完才看到图，体验反而更差。合理的做法是首屏图片直接加载，下方内容再懒加载。
- 检查首屏图片是否被误加了懒加载属性；
- 检查懒加载脚本本身是否阻塞渲染；
- 检查样式表是否被放在了页面末尾，导致首屏出现无样式闪烁。
第五步：alt 与文件名顺手一起看
alt 文本的作用是图片加载失败时提供说明，也是无障碍访问的基础。自查时关注两点：有没有漏写 alt，以及是不是所有图片都写了同一句话。文件名同理，pic-001.jpg 这类命名对任何一方都没有帮助，换成能描述内容的英文或拼音更有意义。
把它变成一张可复用的检查表
- 导出一次全站资源清单，按请求量从高到低排序；
- 筛出状态码非 200 的资源，逐个确认是删除还是修复；
- 筛出体积偏大的图片，对照展示尺寸判断是否需要重做；
- 核对首屏资源是否被懒加载或阻塞；
- 抽查 alt 与文件名，确认没有大面积重复或空缺；
- 记录本次处理结果，下次自查时对比变化。
这套检查不需要很高的技术门槛，但需要固定的节奏。把它放进季度维护或改版前后的运营清单里，通常比临时发现问题再补救要省事得多。