TTFB是什么，多少算正常
TTFB（Time to First Byte） 是从浏览器发出 HTTP 请求到收到服务器第一个字节的时间，代表服务器处理请求的速度。
参考标准（Google Core Web Vitals）：
– ✅ 良好：< 800ms（TTFB本身，Google CWV中的LCP关联标准）
– ⚠️ 需改进：800ms – 1800ms
– ❌ 较差：> 1800ms
实际优化目标（动态页面）：
– < 200ms：优秀（托管主机/高性能VPS）
– 200-500ms：良好（主流共享主机 + 缓存）
– 500ms-1s：需优化
– > 1s：严重问题，需立即排查
测量工具：
– Google PageSpeed Insights（真实用户数据 + 实验室数据）
– GTmetrix（选择离目标用户近的测试节点）
– Chrome DevTools → Network → 第一个请求的 TTFB
TTFB 的构成
TTFB 由三部分叠加：
1. 网络延迟（客户端 → 服务器的物理距离）
2. 服务器处理时间（PHP执行 + 数据库查询）
3. 排队等待时间（服务器并发处理能力不足时）
排查时需要区分是哪个环节拖慢了 TTFB。
第一层：网络延迟排查
判断方法
在 Google Cloud Speed Test 或 CloudPing 测试你的服务器IP到目标用户地区的延迟：
– 美国用户 → 美国服务器：正常 20-50ms
– 中国用户 → 美国服务器：正常 150-200ms（物理距离决定，无法消除）
如果仅网络延迟就超过 200ms，说明服务器地区选错了，需要换节点。
解决方案：CDN
Cloudflare 免费 CDN 可以将静态资源分发到离用户最近的边缘节点，将网络延迟从 200ms 降到 20-50ms。
对于动态页面，启用 Cloudflare APO（$5/月）可以将WordPress动态页面也缓存在边缘，TTFB降至 30-80ms（全球）。
第二层：服务器响应时间排查
先排除网络延迟，用服务器本地工具测试：
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}\nTotal: %{time_total}\n" https://yourdomain.com
如果本地测试 TTFB < 100ms，但远程测试 > 500ms，问题在网络层（用CDN解决）。
如果本地测试也 > 300ms，问题在服务器处理层。
PHP-FPM 配置排查
检查 PHP-FPM 进程数是否不足：
# 查看PHP-FPM进程状态
sudo systemctl status php8.2-fpm
# 检查进程数配置
cat /etc/php/8.2/fpm/pool.d/www.conf | grep pm.max_children
对于 1GB RAM 的服务器，pm.max_children 建议设为 10-20。
宝塔面板： PHP管理 → 配置修改 → pm.max_children 数值调大。
第三层：PHP 执行时间排查
PHP 执行慢通常来自：
1. 没有开启 OPcache（每次请求重新编译PHP文件）
2. 插件质量差（大量无效逻辑、未优化的循环）
3. 主题过于复杂（页面构建器生成大量嵌套代码）
开启 OPcache
在 php.ini 中确认以下配置：
opcache.enable=1
opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000
opcache.revalidate_freq=2
OPcache 开启后，PHP 执行时间通常降低 30-50%。
用 Query Monitor 定位慢插件
安装 Query Monitor 插件，在浏览器访问问题页面，检查：
- PHP execution time（PHP总执行时间）
- Database queries（数据库查询次数和最慢查询）
- Hooks（哪个 action/filter 钩子耗时最长）
PHP 执行时间 > 500ms 说明有严重的插件或主题问题。
第四层：数据库查询排查
WordPress 的 TTFB 问题中，数据库查询慢占 60% 以上的原因。
慢查询日志
在 MySQL 配置中开启慢查询日志（阈值设为 1秒）：
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';
然后查看日志找出最慢的查询，通常来自特定插件的 SELECT 语句缺少索引。
wp_options autoload 问题
WordPress 启动时会加载所有 autoload=yes 的 options，如果 autoload 数据总量超过 800KB，启动开销非常大。
排查：
SELECT SUM(LENGTH(option_value)) as autoload_size
FROM wp_options
WHERE autoload='yes';
如果结果 > 800KB，需要清理或禁用部分插件的 autoload 数据。
启用 Redis 对象缓存
Redis 对象缓存将 MySQL 查询结果缓存在内存中，相同查询第二次直接从内存返回，跳过 MySQL，将数据库密集操作的响应时间降低 60-90%。
安装：
1. 在服务器安装 Redis（apt install redis-server）
2. WordPress 安装 Redis Object Cache 插件
3. 在插件设置中启用连接
第五层：缓存层排查
如果前四层都排查过了，TTFB 仍然偏高，考虑是否缓存配置有问题：
页面缓存是否生效
用 curl -I https://yourdomain.com 查看响应头：
– 有 X-Cache: HIT 或 CF-Cache-Status: HIT：缓存命中，不经过PHP
– 没有或显示 MISS：每次请求都重新执行PHP
未命中的常见原因：
– 登录状态下页面缓存被绕过（用无痕浏览器测试）
– 插件设置了 no-cache 响应头
– 购物车 Cookie 导致动态内容不被缓存
TTFB 优化路线图
TTFB > 1s
│
├─ 是否开启缓存？
│ └─ 未开启 → 安装LiteSpeed Cache / WP Super Cache → TTFB可降至100-300ms
│
├─ 缓存已开启，仍然慢？
│ ├─ 安装Query Monitor → 查数据库查询次数
│ ├─ 启用Redis对象缓存
│ └─ 排查高CPU插件
│
├─ 服务器处理正常，但远程测试慢？
│ └─ 网络延迟问题 → 开启Cloudflare CDN / 换更近节点
│
└─ 共享主机资源限制？
└─ 考虑迁移到Cloudways或VPS
实战案例：TTFB从1.2s降到180ms
某外贸独立站（共享主机，WooCommerce 50个SKU）：
原始状态： TTFB 1,200ms（未开缓存，12个插件，autoload 数据1.2MB）
优化步骤：
1. 安装 LiteSpeed Cache，开启页面缓存：→ 820ms
2. 清理 wp_options autoload（删除弃用插件遗留数据）：→ 580ms
3. 启用 Redis 对象缓存：→ 320ms
4. 删除 3 个冗余插件，替换 1 个慢插件：→ 220ms
5. 套上 Cloudflare，启用 Browser Cache TTL：→ 180ms
全程未升级主机套餐，仅通过优化配置实现 85% 的 TTFB 降幅。