蜘蛛爬到入口頁，第一件要做的事是把 HTML 拉回去解析。頁面体积越大，這件事越慢；更麻烦的是，某些搜尋引擎在超過一定字节數之後會停止處理，後面的内容相当于没被看到。入口頁作為蜘蛛進入站点的第一落点，体积控制值得單獨拿出来说。
蜘蛛到底會讀多少 HTML
Google 的文档里提到過，索引系統對單個 HTML 文件的處理上限大约在 2MB 量級，超出的部分可能不參與索引，脚本和样式等资源還有另外的額度。Bing 也有類似的截断行為。這些數字會随引擎更新變化，不是硬性保證，但方向一致：越靠後的内容，越容易被放弃。
所以体积問题的本质並不是「必须小于某個 KB」，而是「你想让蜘蛛看到的東西，有没有落在它一定會讀到的位置」。
体积通常被什么撑大
- 内联的 JS 和 CSS。為了减少請求，把整套样式和脚本塞進 head，一個頁面几十上百 KB 很常见。
- base64 内嵌的图片、字体和图标。一張 200KB 的图轉成 base64 之後体积還會再涨约三分之一。
- 重复的 DOM 结构。列表、卡片、導航逐條展開，外加多层包裹，正文被一路推到文件尾部。
- 框架生成的冗余属性。data-* 标记、水合所需的大量狀態資料，人在頁面上看不到，但字节一個不少。
把關键信息往前提
蜘蛛解析 HTML 是顺序進行的，先讀到的先被理解。因此入口頁的结构顺序，往往比單纯压缩体积更重要：
- head 里先放 title、meta description、canonical、robots 等關键指令，再放样式和脚本。
- body 開头就出現與頁面主题相關的可见文字，而不是一張大图加几十行導航。
- 正文里的主要連結尽量安排在前半部分，不要全部埋在頁脚的密集連結区。
一個简單的判断方法：把頁面源碼的前 100KB 單獨拿出来看，如果标题、主体文案和主要連結都已经在里面，說明结构是健康的。
懒加载與無限滚動的盲区
不少入口頁用懒加载省流量，图片和列表在滚動时才加载。問题在于，蜘蛛不一定滚動頁面，也不一定完整执行滚動脚本。结果是人在頁面上看得到的内容，蜘蛛拿到的 HTML 里只剩占位符。
比較稳妥的做法是：首屏和主体内容用服務端渲染直接輸出，懒加载只留给确實靠後的次要资源；無限滚動則配一個可訪問的分頁或「查看更多」連結，让内容有一條不依赖脚本的路径。
三個可以立刻做的自查
- 用命令行抓一次頁面並統計字节數：curl -s URL | wc -c，看看是否明顯超過预期。
- 查看網頁源代碼（不是開發者工具里渲染後的 DOM），確認主体文案和連結在原始 HTML 中确實存在。
- 翻抓取日誌或服務器訪問记錄，看蜘蛛實际拿到的字节數和耗时，與自己的预期對不對得上。
体积和抓取预算的關系
抓取预算是有限的。蜘蛛在單位時間内能處理的字节數有上限，入口頁越臃肿，同样時間能翻的頁面就越少，留给其他 URL 的額度也跟着紧張。控制体积不是為了讨好某個數字，而是让每一次来訪都尽量有效率。反過来也不必為了极致瘦身把頁面拆得七零八落，可讀性和维護成本同样要算進去。
几條實践建议
- 把可缓存的 CSS 和 JS 拆成外部文件，靠缓存與压缩解决，不要每頁重复内联。
- 图片走常規 URL 交给浏览器缓存，base64 只用于极小的图标。
- 入口頁保持结构清晰，正文與主要連結別被脚本、样式挤到文件尾端。
- 站点模板难免有大段公共结构时，至少让正文在 HTML 中出現得足够早。
体积只是入口頁健康度的一個维度，它和响應時間、狀態碼、内容更新一起，影响蜘蛛愿不愿意繼續往下走。單獨優化一項很难有质變，但任何一項明顯拖後腿，都會让其他的努力打折。