响应时间为什么值得单独盯着
蜘蛛来一个页面，要先建立连接、等服务器返回第一个字节，再把整页读完。这三步里任何一步卡住，都会占着它的连接和配额。搜索引擎给一个站点的抓取量并不是无限的，服务器慢，蜘蛛往往就会降低来访频次——这不是惩罚，而是它把时间挪去别处了。所以响应时间是运营的基础项，地基不稳，内容和结构做得再好也容易打折。
先分清是服务器慢还是页面大
- TTFB（首字节时间）：服务器处理一个请求要多久。
- 完整下载时间：首字节之后，把 HTML 传完花多久。
- 连接阶段：DNS、TCP、TLS 握手的耗时。
- 状态码分布：5xx、超时、连接重置各占多少。
如果 TTFB 高但下载很快，问题多半在服务端；如果 TTFB 正常却下载慢，那更可能是 HTML 体积或带宽的问题。两个方向的处理手段完全不同，先分清再动手，能省下不少无用功。
不用复杂工具也能自查
- 用命令行对一个典型 URL 计时，连续跑几次，看波动幅度。
- 浏览器开发者工具的网络面板，看每个阶段的耗时分布。
- 翻服务器访问日志，筛出蜘蛛的 UA，按响应码和耗时排序。
- 把同一批 URL 放在不同时段对比，区分偶发和常态。
只看首页是不够的。首页往往挂了缓存，栏目页和详情页才是真实水平。
常见的几类原因
- 数据库慢查询，列表页每次请求都要重新聚合一遍。
- 没做页面缓存或对象缓存，每个请求都走完整逻辑。
- 应用冷启动，进程被回收后第一批请求特别慢。
- 共享主机上被邻居抢占资源，表现时好时坏。
- 定时任务、备份、日志切割正好撞上抓取高峰。
- 大文件和动态页面放在同一环境里互相挤带宽。
处理的先后顺序
先加缓存，通常是性价比最高的一步；再优化最耗时的查询和循环；然后考虑把稳定不变的页面静态化，或把静态资源交给 CDN；最后才是升级配置。顺序反过来，钱花了不少，效果却未必明显。
关于蜘蛛池的一点说明
蜘蛛池解决的是引导蜘蛛来访的问题，解决不了来了之后服务器扛不扛得住。如果响应本来就慢，拉来更多请求只会让情况更糟，日志里 5xx 的比例也会往上走。这两件事应当分开看：先把站点自身的响应打理好，再谈引流与发现。
把它变成日常动作
- 关键页面加监控，超过阈值就告警。
- 小改动之后就复测，别等到下一次大改版。
- 看 5xx 和超时的趋势，而不是某一天的孤立数值。
- 记录每次调整前后的数据，方便回溯原因。
响应时间是那种平时不出声、出问题时很棘手的基础项。它不需要天天折腾，但值得有一个固定的观察位置。