图片和静態资源為什么值得單獨查一遍
很多站点运营把注意力放在頁面和連結上，图片、CSS、JS、字体這些静態资源却很少被翻出来看一遍。它們不直接决定頁面能不能被收錄，但會實實在在影响加载速度、渲染完成時間，也會占用服務器的請求數和带宽。当站点的抓取請求額度有限时，把額度花在几百張没压缩的大图和一堆已经失效的文件上，顯然不划算。
這類問题的麻烦之處在于它不會报错，頁面看上去一切正常，只有打開開發者工具或者翻日誌才會發現異常。所以更适合按固定清單定期過一遍，而不是等出問题再查。
第一步：把頁面實际加载的资源列出来
不要凭记忆列清單，要以真實加载结果為准。常用做法有三種：
- 用浏览器開發者工具的 Network 面板，勾選 Disable cache 後刷新，查看全部請求；
- 用站点爬虫工具抓一遍全站，筛出图片、样式、脚本、字体這几類资源；
- 翻服務器訪問日誌，按文件後缀統計請求量和狀態碼分布。
三種方式视角不同：開發者工具看的是單個頁面的真實加载，爬虫看的是全站覆盖，日誌看的是實际被請求最多的那些文件。三者對照，問题基本藏不住。
第二步：先把失效资源清掉
這一步優先級最高，因為它是纯损耗。重点看两類：
返回 404 或 403 的资源
常见来源是改版时删掉的图片目錄、被替換掉的舊样式文件、寫错路径的引用，以及外鏈图床失效。图片缺失时頁面不會报错，只會留一块空白，用戶和蜘蛛都看不到那里的内容。
長期超时或跨域加载失敗的资源
如果頁面上引用了第三方 CDN 的脚本或字体，而對方响應很慢甚至偶尔失敗，頁面渲染就會被拖住。可以定期核對一次外部资源的可用性和响應時間，把不必要的依赖去掉。
判断标准很简單：這個文件如果加载失敗，頁面内容還能不能完整看到？答案是否，就该優先處理。
第三步：核對体积、尺寸與格式
尺寸是否和展示位置匹配
把 2000 像素宽的图缩到 300 像素的缩略图位置展示，是最常见的浪費。上传前先按實际展示宽度裁剪，而不是交给 CSS 缩放。
格式是否合适
- 照片、插画類内容：優先用 WebP 等現代格式，保留 JPEG 作為兜底；
- 图标、简單图形：用 SVG，通常比位图小很多且缩放不模糊；
- 截图、带文字的图：注意压缩後文字是否還清晰，不要一味追求最小体积。
压缩是否做到位
用批量压缩工具走一遍，通常能砍掉不少体积，且肉眼几乎看不出差別。注意保留原图备份，方便以後重新導出不同尺寸的版本。
第四步：首屏资源與懒加载
懒加载本身没問题，但用错位置會带来副作用。如果首屏大图也设了懒加载，用戶打開頁面时可能要等脚本执行完才看到图，体驗反而更差。合理的做法是首屏图片直接加载，下方内容再懒加载。
- 检查首屏图片是否被誤加了懒加载属性；
- 检查懒加载脚本本身是否阻塞渲染；
- 检查样式表是否被放在了頁面末尾，導致首屏出現無样式闪烁。
第五步：alt 與文件名顺手一起看
alt 文本的作用是图片加载失敗时提供說明，也是無障碍訪問的基础。自查时關注两点：有没有漏寫 alt，以及是不是所有图片都寫了同一句话。文件名同理，pic-001.jpg 這類命名對任何一方都没有帮助，換成能描述内容的英文或拼音更有意义。
把它變成一張可复用的检查表
- 導出一次全站资源清單，按請求量從高到低排序；
- 筛出狀態碼非 200 的资源，逐個確認是刪除還是修复；
- 筛出体积偏大的图片，對照展示尺寸判断是否需要重做；
- 核對首屏资源是否被懒加载或阻塞；
- 抽查 alt 與文件名，確認没有大面积重复或空缺；
- 记錄本次處理结果，下次自查时對比變化。
這套检查不需要很高的技術门槛，但需要固定的节奏。把它放進季度维護或改版前後的运营清單里，通常比临时發現問题再补救要省事得多。