很多站点在排查抓取問题时，习惯先看 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 中可见；
- 清理長期無訪問且已不再被引用的舊资源；
- 固定一個周期回看，避免新上传的素材重新把体积堆起来。
图片和静態资源的自查不太像“技術难题”，更像一次整理。它不會立刻带来什么變化，但能减少每一次抓取和每一次訪問的無效消耗。對内容量在增長的站点来说，這種整理越早做，後面越省事。