為什么入口頁的性能要單獨拿出来看
蜘蛛在多個站点之間爬行时，每個站点分到的時間是有限的。同一批連結里，如果某個入口頁响應慢、资源多、等了半天才返回，爬虫通常不會一直等下去，而是把這次抓取算作一次消耗，然後轉向下一站。入口頁本身不承载轉化，它的任務是把蜘蛛接住，並且尽快送到下一跳，所以轻比好看更重要。
頁面体积：先看 HTML 本身
入口頁的 HTML 通常只需要标题、一段可讀的文字、几條指向目标頁的連結，以及必要的 meta 信息。統計脚本、在线客服、轮播图、评论组件這些東西，對入口頁没有實际作用，只會增加体积和請求。
内联還是外鏈
少量 CSS 直接内联在 head 里，可以省掉一次請求；如果样式确實較多，合並成一個外鏈文件反而更合适。這里没有绝對答案，關键是在請求數和体积之間找個平衡点，別為了省一次請求把 HTML 撑到几百 KB。
請求數：体积不大但請求太多同样拖慢
很多入口頁 HTML 不到 100KB，但請求數有三四十個，其中大半来自第三方脚本。蜘蛛不一定去抓這些资源，但服務器的處理压力和頁面可用性會受影响，尤其是並發上去之後。
- CSS 合並成一個文件，不要每個组件單獨一個
- JS 能不用就不用，入口頁通常不需要交互逻辑
- 图片數量控制，入口頁一般不需要大图
- 字体文件谨慎引入，体积大且容易阻塞渲染
- 統計、客服、广告類第三方脚本，能不放就不放
一個经驗：入口頁的首屏請求數控制在個位數，總传輸量控制在百 KB 以内，大多數场景就够用了。
服務端响應：TTFB 是第一道關
頁面再小，如果服務端要等两秒才吐出第一個字节，前面的優化都白做。入口頁尽量走静態化或缓存，避免每次請求都去查資料库。
- 資料库查询：入口頁内容變動少，适合生成静態文件
- 外部接口：不要在入口頁同步調用第三方接口，一旦超时會连带整頁卡住
- 同机站点數量：一台服務器上堆太多站点，容易互相挤占资源
超时設定：別让蜘蛛等到连接被断
服務端超时、反向代理超时以及 keep-alive 的配置需要保持一致。如果上游设 30 秒才超时，中間那层 10 秒就断開，蜘蛛拿到的是不完整的响應。静態入口頁正常情况下應该在几百毫秒内返回，配置超时时按這個量級来设，留一点余量即可。
不要做成必须跑 JS 才能看到内容的頁面
單頁應用、纯前端渲染、懒加载，這些對入口頁都没有好處。蜘蛛拿到的 HTML 如果是空壳，連結和文字都取不到，等于白来一趟。用服務端渲染，或者干脆輸出静態 HTML，是更稳妥的做法。
怎么观察和驗證
- 看服務器日誌里的响應時間字段，找出明顯偏慢的入口
- 對比頁面調整前後的抓取频次，看是否有變化
- 從外部網絡實测一次，確認不是内網测速造成的假象
- 批量抽检若干入口頁，比較首字节時間和總传輸量
几個常见誤区
- 以為蜘蛛不抓图片，所以图片可以随便放
- 為了让頁面顯得内容丰富，引入大量外部资源
- 把超时设得特別長，認為等久一点總能返回
- 只在本地环境测速，忽略了實际线路和 CDN 回源
小结
入口頁的性能不需要做到极致，但要有基本的下限：体积小、請求少、响應快、超时可控。把這几件事做稳，蜘蛛才有机會在有限的時間里繼續往下走。