WordPress 变慢？用 Query Monitor 定位真实瓶颈

先说结论：WordPress 变慢有且只有三个来源——PHP 执行慢、数据库查询多、前端资源重。凭感觉删插件是瞎猜；装一个 Query Monitor，5 分钟就能看出该修哪里。

第 0 步：先量出基线，别凭感觉

• 用 Chrome Lighthouse 或 PageSpeed 测一次首页与文章页，记下 TTFB 和总加载时间。
• 命令行测 TTFB：curl -o /dev/null -s -w '%{time_starttransfer}\n' 你的网址
• 基线数据是后面判断「到底优化了没有」的唯一依据。

判断口径：TTFB < 200ms 正常；200–600ms 有优化空间；> 1s 基本是 PHP 或数据库问题，不是图片问题。

装 Query Monitor（只在登录状态下生效，不影响访客）

后台搜索安装启用后，前台页面底部会出现一个黑色工具条，这就是它的入口。重点看四块：

瓶颈一：数据库查询过多（Queries 面板）

如果总查询数超过 100，看「按调用者分组」那一栏，它会直接告诉你是哪个插件、哪个主题函数在发查询。常见元凶：

• 相关文章插件：每篇调一次查询，列表页 × 10 条 = 10 次。
• 浏览量统计：每次访问写一次数据库，高并发时是灾难。
• 面包屑、标签云、随机文章：看似小，但在列表页重复执行。

处理思路：能关就关，不能关就加对象缓存（Redis）或静态化。

另一个高频问题是「慢查询」——Query Monitor 会把超过阈值的查询标红。看到 SELECT ... WHERE meta_value = ... 就要注意，这是 postmeta 表没有索引导致的，数据量一大必然拖慢。

瓶颈二：外部 HTTP 请求卡住页面（HTTP API 面板）

这个最隐蔽。WordPress 的很多功能（字体、验证码、更新检查、统计、地图）会在页面渲染时同步请求外部地址。如果对方响应慢或超时，你的页面就跟着等。

• 看 HTTP API 面板里的耗时，有单条超过 500ms 的立即处理。
• 能改异步的就异步，能本地化的就本地化（比如把 Google 字体下载到本站）。
• 实在要保留外部请求，给个短超时，别用默认值。

瓶颈三：PHP 执行慢（Timing 面板）

查询不多但 PHP 耗时高，通常是：

• PHP 版本低：7.4 到 8.1 一般能快 20%–40%，这是最高性价比的一次操作。
• OPcache 没开：面板里确认 opcache.enable 为 On。
• 内存上限太小导致频繁 GC：WP_MEMORY_LIMIT 提到 256M 试试。

瓶颈四：前端资源（不属于 PHP 层，但影响最大）

PHP 已经很快、页面还是慢，就转向前端：

• 图片没压缩、没转 WebP，几张 2MB 的图能毁掉一切优化。
• 插件无差别加载 CSS/JS：用一个资源管理插件按页面关闭不用的。
• 字体图标库整包引入，实际只用 3 个图标。

一套可复制的排查顺序

1. 测 TTFB，判断是服务端还是前端问题。
2. TTFB 高 → 开 Query Monitor 看 Queries 与 Timing。
3. 查询多 → 找具体插件，能关就关。
4. PHP 慢 → 升版本、开 OPcache、加内存。
5. TTFB 正常 → 转前端，压图片、减请求、加缓存。

不要同时改五样东西再测，那样即使变快了也不知道是哪一步起了作用。每次只改一项，改完测一次。