很多站点在排查抓取问题时，习惯先看 robots.txt、站点地图和状态码，却很少把目光放到图片和静态资源上。实际上，一个页面里真正占体积的往往不是文字，而是几张没压缩的图、几个没合并的脚本，以及一堆用不到的字体文件。它们不会直接报错，但会持续消耗带宽、拉长渲染时间，也会让蜘蛛在同样的时间里能走的页面变少。
为什么静态资源值得单独自查
蜘蛛抓取一个页面，不只是取回 HTML。它还要根据页面里的引用去请求 CSS、JS 和图片，才能理解页面长什么样。如果这些资源体积大、请求多、响应慢，会带来几个连锁反应：
- 单页抓取耗时变长，同样的抓取资源下能覆盖的页面数下降；
- 服务器带宽被重复消耗，尤其是图片没有设置缓存头的时候；
- 移动端访客等待时间变长，中途离开的比例上升；
- 图片地址失效或返回错误状态，页面出现空缺，影响观感。
一份可以照着做的自查清单
1. 文件体积与格式
先统计图片目录里体积最大的前几十个文件。常见的浪费包括：把相机直出的大图直接上传、用 PNG 存照片、同一张图同时存在多种格式却没有替换旧的。照片类内容更适合用压缩后的 JPEG 或 WebP，图标和线条图再用 PNG 或 SVG。
2. 展示尺寸与实际尺寸
一张 2000 像素宽的图，被塞进 300 像素宽的卡片里，是很常见的浪费。检查 CSS 里设定的展示宽度，尽量让图片的实际像素接近展示尺寸的两倍以内（兼顾高清屏），而不是一律上传原图。
3. 请求数量
每个页面加载了多少个 CSS、JS、字体和图片文件？请求数过多时，即使每个文件都不大，叠加起来也会拖慢首屏。可以合并同类小文件、去掉没有用到的样式库、检查是否引入了整套 UI 框架却只用了一两个组件。
4. 缓存头与文件名
静态资源如果能被浏览器和中间层缓存，重复访问时就不必重新下载。检查服务器是否给图片、CSS、JS 设置了合理的缓存时间。同时，更新文件内容时建议改变文件名或在文件名里带版本号，避免访客拿到旧文件。
5. 加载方式
首屏之外的图片可以延迟加载，避免一次性请求全部资源。但要注意懒加载的实现方式：如果图片地址写在脚本里、HTML 中没有可识别的 src，蜘蛛可能拿不到图片信息。对希望被索引的图片，保留常规的 img 标签和 alt 描述会更稳妥。
6. 失效与错误资源
抽查页面是否存在 404 的图片、指向已删除文件的脚本、写错路径的字体。可以在浏览器控制台查看报错，也可以从服务器日志里筛选静态资源目录下的 4xx 记录。这些请求同样是抓取资源的一部分，没有必要一直留着。
7. 图片本身的收录信息
如果站点依赖图片搜索带来访问，可以检查图片是否有清晰的 alt、是否放在与主题相关的页面里、图片地址是否稳定。图片站点地图有助于蜘蛛发现图片地址，但它解决的是发现效率，并不保证结果。
几个容易忽略的细节
静态资源的问题通常不会在日志里以“错误”的形式出现，而是以“变慢”和“变少”的形式出现，所以更容易被忽略。
- 同一张图在多个页面重复引用时，是否指向同一个地址，而不是各自复制一份；
- 是否还有早已下线的活动页图片、旧版 logo 留在服务器上被引用；
- 外部 CDN 或第三方脚本如果响应很慢，也会拖住整个页面的加载；
- 字体文件是否包含大量用不到的字符集和字重。
建议的落地顺序
- 导出最近的静态资源访问日志，按时长和体积排序，找出最重的若干个；
- 针对体积最大的图片做压缩和格式转换，原图另存备份；
- 检查页面请求数量，删掉确认没有使用的引用；
- 确认缓存策略和文件名版本机制；
- 对首屏外的图片启用懒加载，同时确认图片地址在 HTML 中可见；
- 清理长期无访问且已不再被引用的旧资源；
- 固定一个周期回看，避免新上传的素材重新把体积堆起来。
图片和静态资源的自查不太像“技术难题”，更像一次整理。它不会立刻带来什么变化，但能减少每一次抓取和每一次访问的无效消耗。对内容量在增长的站点来说，这种整理越早做，后面越省事。