本文约 3,283 字，预计阅读 9 分钟。文中命令与配置均经过实测，可直接参考执行。
引言：服务器一慢，最先掉的不是用户体验，是收录
很多站长把网站速度当成纯体验问题，直到发现索引量长期卡在某个数字上不去、新文章发布一周还没被抓取，才开始怀疑是速度拖了后腿。这个怀疑往往是对的。Baiduspider 分配给每个站点的抓取配额是有限的，它按「单位时间能抓多少页」来调度。你的页面平均响应 2 秒，它在同样的时间窗里只能抓 500 页；如果压到 200 毫秒，同样的窗里能抓 5000 页。配额用不完的站，新内容自然排不上队。更极端的情况是页面偶尔返回 5xx 或超时，爬虫会主动下调抓取频次，进入恶性循环。所以速度不是「体验优化项」，而是实打实的收录前提。
原理分析：抓取预算由三个变量决定
抓取预算（Crawl Budget）在百度的语境里没有官方量化公式，但从资源平台的「抓取频次」工具和站长实测可以归纳出三个主导变量：响应速度（TTFB）、稳定性（错误率）、站点权重（历史更新质量与外链）。前两个是站长完全可控的，第三个是长期结果。百度在 2018 年推出的闪电算法，明确把移动网页首屏打开时间作为排序因素，3 秒内打开的页面在移动搜索里会获得展现优待，这条至今有效。
| 指标 | 合格线 | 优秀线 | 测量方式 |
|---|---|---|---|
| TTFB（首字节） | < 800ms | < 200ms | curl time_starttransfer |
| 首屏渲染（移动） | < 3s | < 1.5s | Lighthouse / 百度闪电算法口径 |
| HTML 完全下载 | < 1s | < 300ms | curl time_total |
| 5xx / 超时占比 | < 0.5% | < 0.1% | 日志统计 |
| 并发稳定 | 20 并发不超时 | 100 并发不超时 | ab / wrk |
注意区分「慢」和「不稳」。慢只是抓取效率低；不稳（间歇性 502/504）会让百度判定站点不可靠，直接削减频次，后者的杀伤力大得多。
保姆级实操
步骤 1：先用数据确认是不是真的慢。 不要凭打开感觉判断，用 curl 量化，并且用百度蜘蛛的 UA 去测，避免缓存插件只给真人提速：
UA='Mozilla/5.0 (compatible; Baiduspider/2.0; +http://www.baidu.com/search/spider.html)'
URL='https://mimangfei.com/'
for i in 1 2 3 4 5; do
curl -sS -o /dev/null -A "$UA" --max-time 10 \
-w "第${i}次 DNS=%{time_namelookup}s 连接=%{time_connect}s TTFB=%{time_starttransfer}s 总耗时=%{time_total}s 状态=%{http_code}\n" \
"$URL"
done
步骤 2：打开 PHP OPcache。 这是 WordPress 提速性价比最高的一步，不用改任何代码。OPcache 把编译后的 PHP 字节码缓存在共享内存里，省掉每次请求重新解析脚本的开销：
; /etc/php/8.2/fpm/conf.d/10-opcache.ini
opcache.enable=1
opcache.memory_consumption=128
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=10000
opcache.validate_timestamps=1
opcache.revalidate_freq=2
opcache.save_comments=1
opcache.jit_buffer_size=64M
改完执行 systemctl reload php8.2-fpm，用 php -i | grep opcache 确认生效。如果内存给得太小，opcache_get_status() 里会看到大量 cache full 重启，反而更慢。
步骤 3：给 HTML 开启压缩。 在 nginx 里启用 gzip，若已编译 Brotli 模块则优先 Brotli。WordPress 的 HTML 是动态生成的，文本压缩率通常能到 70% 以上：
gzip on;
gzip_vary on;
gzip_comp_level 5;
gzip_min_length 1024;
gzip_proxied any;
gzip_types text/plain text/css application/javascript application/json
application/xml text/xml image/svg+xml;
步骤 4：把静态资源与 HTML 分离缓存策略。 图片、CSS、JS 设长缓存加文件名版本号；HTML 不缓存或只做短时缓存。很多站点图省事给 HTML 也设了一天缓存，结果改了内容百度抓到的还是旧的，误以为是收录没更新。
步骤 5：处理数据库慢查询。 WordPress 慢的常见来源是 wp_postmeta 上的查询和未清理的 wp_options 自动加载数据。检查 autoload 体积：
SELECT SUM(LENGTH(option_value)) / 1024 / 1024 AS autoload_mb
FROM wp_options
WHERE autoload = 'yes';
超过 1MB 就该清理，很多废弃插件留下的记录会一直被每次请求加载。
步骤 6：稳定性兜底。 配置 php-fpm 的 pm.max_requests 防内存泄漏，加 request_terminate_timeout 避免单请求拖死进程池，并接上监控告警。日志里定期统计错误码分布：
awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10
grep 'Baiduspider' /var/log/nginx/access.log | awk '{print $9}' | sort | uniq -c
常见踩坑
- 只装了缓存插件，源站本身 TTFB 两秒，缓存只能掩盖真人访问，爬虫第一次抓仍是慢的。
- 案例： 某站开启 OPcache 后内存只给了 64MB，脚本数量超出
max_accelerated_files，缓存频繁被清，平均响应反而比关闭时更慢，排查了两天才从opcache_get_status()的oom_restarts字段看出问题。 - 给 HTML 设了长缓存，改版后百度一直抓旧版，误判为改版失败。
- 用境外服务器面向国内用户，物理延迟就 300ms 起，怎么优化都到不了优秀线。
- 只看首页速度，文章页因为挂了相关文章查询和评论头像，慢三倍却没人测。
- 提速插件同时开三个，功能互相打架，生成大量碎片缓存文件把磁盘 inode 吃满。
- 压测只看平均值，忽略了 P95/P99，偶发 504 才是百度下调频次的主因。
总结
速度与收录的关系可以量化成一句话：在权重相近的前提下，单位时间能被抓完的页面数决定了你的收录上限。行动清单：用百度蜘蛛 UA 测五次 TTFB 取中位数 → 开 OPcache 并核对命中率 → 开 gzip/Brotli → 分离 HTML 与静态资源缓存 → 清理 autoload 与慢查询 → 日志里按周统计 5xx 占比。稳定优先于极致速度，先把错误率压到 0.1% 以下再谈毫秒级优化。5xx 导致的后果与补救见 服务器不稳定导致降权的恢复，首屏体验细节见 移动端首屏加载优化。
