为什么入口页的性能要单独拿出来看
蜘蛛在多个站点之间爬行时，每个站点分到的时间是有限的。同一批链接里，如果某个入口页响应慢、资源多、等了半天才返回，爬虫通常不会一直等下去，而是把这次抓取算作一次消耗，然后转向下一站。入口页本身不承载转化，它的任务是把蜘蛛接住，并且尽快送到下一跳，所以轻比好看更重要。
页面体积：先看 HTML 本身
入口页的 HTML 通常只需要标题、一段可读的文字、几条指向目标页的链接，以及必要的 meta 信息。统计脚本、在线客服、轮播图、评论组件这些东西，对入口页没有实际作用，只会增加体积和请求。
内联还是外链
少量 CSS 直接内联在 head 里，可以省掉一次请求；如果样式确实较多，合并成一个外链文件反而更合适。这里没有绝对答案，关键是在请求数和体积之间找个平衡点，别为了省一次请求把 HTML 撑到几百 KB。
请求数：体积不大但请求太多同样拖慢
很多入口页 HTML 不到 100KB，但请求数有三四十个，其中大半来自第三方脚本。蜘蛛不一定去抓这些资源，但服务器的处理压力和页面可用性会受影响，尤其是并发上去之后。
- CSS 合并成一个文件，不要每个组件单独一个
- JS 能不用就不用，入口页通常不需要交互逻辑
- 图片数量控制，入口页一般不需要大图
- 字体文件谨慎引入，体积大且容易阻塞渲染
- 统计、客服、广告类第三方脚本，能不放就不放
一个经验：入口页的首屏请求数控制在个位数，总传输量控制在百 KB 以内，大多数场景就够用了。
服务端响应：TTFB 是第一道关
页面再小，如果服务端要等两秒才吐出第一个字节，前面的优化都白做。入口页尽量走静态化或缓存，避免每次请求都去查数据库。
- 数据库查询：入口页内容变动少，适合生成静态文件
- 外部接口：不要在入口页同步调用第三方接口，一旦超时会连带整页卡住
- 同机站点数量：一台服务器上堆太多站点，容易互相挤占资源
超时设置：别让蜘蛛等到连接被断
服务端超时、反向代理超时以及 keep-alive 的配置需要保持一致。如果上游设 30 秒才超时，中间那层 10 秒就断开，蜘蛛拿到的是不完整的响应。静态入口页正常情况下应该在几百毫秒内返回，配置超时时按这个量级来设，留一点余量即可。
不要做成必须跑 JS 才能看到内容的页面
单页应用、纯前端渲染、懒加载，这些对入口页都没有好处。蜘蛛拿到的 HTML 如果是空壳，链接和文字都取不到，等于白来一趟。用服务端渲染，或者干脆输出静态 HTML，是更稳妥的做法。
怎么观察和验证
- 看服务器日志里的响应时间字段，找出明显偏慢的入口
- 对比页面调整前后的抓取频次，看是否有变化
- 从外部网络实测一次，确认不是内网测速造成的假象
- 批量抽检若干入口页，比较首字节时间和总传输量
几个常见误区
- 以为蜘蛛不抓图片，所以图片可以随便放
- 为了让页面显得内容丰富，引入大量外部资源
- 把超时设得特别长，认为等久一点总能返回
- 只在本地环境测速，忽略了实际线路和 CDN 回源
小结
入口页的性能不需要做到极致，但要有基本的下限：体积小、请求少、响应快、超时可控。把这几件事做稳，蜘蛛才有机会在有限的时间里继续往下走。