WordPress后台慢怎么办？先定位再下手的 9 个实测提速方法

前台开起来飞快，一进 wp-admin 就转圈。点个”文章”菜单要等好几秒，写着写着编辑器卡一下。我自己的站和帮朋友看的站都碰到过这种情况。

网上的教程我翻了不少，发现两个问题。一是很多方法是给前台用的，放到后台没有任何作用。二是有些代码已经过时了，比如流传很广的 Heartbeat 限速写法，我实测之后发现它在文章编辑器里根本不生效。

所以这篇文章换了个写法：我在本地搭了一套 WordPress 7.1，每个方法都实际测了一遍，测出来的数字直接写进正文。测试环境放在文末，你可以照着复现。

1. 先分清是服务器慢还是浏览器慢

动手改任何东西之前，先花一分钟判断慢在哪一头。不然你装了一堆优化插件，问题可能根本不在那里。

方法很简单。在 Chrome 里打开一个慢的后台页面，按 F12 打开开发者工具，切到 Network（网络）面板，刷新页面。找到列表最上面那条文档请求（就是页面本身，比如 edit.php），点开后看 Timing 里的 “Waiting for server response”。

这个数字就是服务器生成页面花的时间。如果它有好几秒，问题在服务器端，往下看第 2 到第 9 节。如果它只有几百毫秒，页面却还是很久才能用，那就是浏览器在等别的资源。这时候看看列表里有没有一直 pending 的外部请求，第 8 节会讲到。

2. 用 Query Monitor 找出拖后腿的插件

确定是服务器慢之后，下一步是找出谁在耗时间。我一直用 Query Monitor，它是 WordPress 官方插件库里的免费调试插件。我在 10 月 31 日核实过它的状态：当前版本 4.1.1，已测试到 WordPress 7.1.4，活跃安装 20 万以上，4 天前还在更新。

装法和普通插件一样，不熟悉的可以看这篇插件安装方法。启用后，后台顶部工具栏会多出一组数字，包括页面生成时间、内存和查询次数。点开之后有两个面板最有用：

• 按组件汇总的查询： 官方说明是可以把数据库查询按”负责的插件、主题或函数”分组，还会标出慢查询、重复查询和出错的查询。哪个插件的查询最多、最慢，一眼就能看出来。
• HTTP API Calls： 每个外部请求都会列出响应码、是哪个组件发出的、花了多长时间。很多后台慢就是某个插件在每次加载时去连国外的授权服务器，连不上就一直等到超时。

找到嫌疑插件以后，最稳的做法是在测试站上停用它，再对比一次 Query Monitor 的数字。生产站别一口气停用全部插件，会影响访客。

3. 页面缓存救不了后台，对象缓存才行

很多人后台慢的第一反应是装缓存插件。这招对前台有用，对后台基本没用。

原因写在 WordPress 核心代码里：wp-admin/admin.php 一开头就会调用 nocache_headers()。我实测抓到的后台响应头是 Cache-Control: no-cache, must-revalidate, max-age=0, no-store, private。也就是说，后台每个页面都要求浏览器和中间层不要缓存，每次打开都是 PHP 现场生成的。WP Rocket 这类页面缓存插件优化的是前台，想提升访客打开速度可以看这篇前台速度优化完整指南。

后台真正能用上的是持久化对象缓存。WordPress 官方文档对 WP_Object_Cache 的说明是：对象缓存默认不持久，数据不会跨页面保存，除非你装了持久化缓存插件。它列出的方案里包括 Redis Object Cache，作用是给对象缓存提供持久化后端。装好以后，后台反复读取的选项、文章、用户数据会直接从内存里拿，不用每次都查数据库。

具体做法是服务器上先运行 Redis 服务，再装 Redis Object Cache 插件并启用，连接参数按插件说明填写。

顺便说一个检查点。WordPress 6.1 起，”站点健康”里有持久化对象缓存和页面缓存两项检查，但我看了 7.1 的源码，这两项只在环境类型为 production 时才会出现。如果你在 wp-config.php 里把 WP_ENVIRONMENT_TYPE 设成了 staging 或 local，站点健康里就看不到这两项，这是正常的。

4. 后台内存要改 WP_MAX_MEMORY_LIMIT，不是 WP_MEMORY_LIMIT

后台白屏、报 “Allowed memory size exhausted”，或者进某些页面特别卡，可能是内存不够。很多教程会让你改 WP_MEMORY_LIMIT，但后台用的其实是另一个常量。

WordPress 核心源码的逻辑是这样的：wp-admin/admin.php 会调用 wp_raise_memory_limit( 'admin' )，把内存提到 WP_MAX_MEMORY_LIMIT。这个常量如果你没设，默认是 256M。WP_MEMORY_LIMIT 管的是前台，默认 40M（多站点 64M），而且它只会往上调，不会把服务器原本更高的限额调低。

我把 PHP 的 memory_limit 设成 128M，测出来的结果是：

• 不加任何常量： 前台 128M，后台被自动提到 256M。
• wp-config.php 里写 WP_MAX_MEMORY_LIMIT 为 512M： 后台变成 512M，前台还是 128M。
• 把 WP_MEMORY_LIMIT 设成 96M： 前台仍然是 128M。因为 96M 比服务器原值低，WordPress 不会去改它。

所以后台内存不够时，在 wp-config.php 的 /* That's all, stop editing! */ 这行上面加：

php

define( 'WP_MAX_MEMORY_LIMIT', '512M' );

这里有两点要说清楚。一是内存够用之后，再加并不会让后台更快，它解决的是”不够用”导致的报错和白屏。二是如果你的主机用 php_admin_value 锁死了 memory_limit，WordPress 改不动它，这个常量就不会生效。核心代码会先用 wp_is_ini_value_changeable() 检查能不能改，改不了就直接跳过。

5. 管住 Heartbeat：用 minimalInterval，别再用 interval

Heartbeat 是 WordPress 后台的”心跳”，会定时向 admin-ajax.php 发请求，用来处理文章锁定、登录过期提醒、自动保存等功能。每一次心跳都是一个完整的 WordPress 加载过程。后台标签开得多，请求就成倍增加，这也是很多主机商抱怨 admin-ajax.php 占用高的原因。

先纠正一个过时的说法。不少教程写”编辑器里每 15 秒心跳一次”，这是旧数据。WordPress 6.7 的 Trac #61960 把文章列表页和经典编辑器从 15 秒改成了 10 秒，块编辑器也被设成 10 秒。其他后台页面默认是 60 秒。

我实测了 65 秒，结果和这个对得上。仪表盘只在第 61 秒发了 1 次心跳。块编辑器在第 11、21、31、41、51、61 秒各发了一次，一共 6 次。

接下来是关键。网上流传最广的限速代码长这样：

php

add_filter( 'heartbeat_settings', function ( $settings ) {
    $settings['interval'] = 60;
    return $settings;
} );

我把它装上再测块编辑器，65 秒内还是 6 次请求，每 10 秒一次，完全没变。原因在核心代码里：块编辑器加载完成后会执行 wp.heartbeat.interval( 10 )，直接把你设的 interval 覆盖掉了。经典编辑器的 post.js 和文章列表页的 inline-edit-post.js 里也有同样的调用。

真正有用的参数是 minimalInterval。heartbeat.js 源码对它的注释大意是：用来限制 Ajax 请求的数量，比它短的间隔一律被它覆盖，是给扛不住频繁请求的主机准备的；最大可以设到 600 秒，但超过 120 秒会限制或关闭部分功能，比如文章锁定。我改成下面的写法再测，130 秒内只在第 61 秒和第 121 秒各发了一次，编辑器的心跳从 10 秒变成了 60 秒：

php

<?php
/**
 * Plugin Name: Heartbeat 限速
 */
add_filter( 'heartbeat_settings', function ( $settings ) {
    $settings['minimalInterval'] = 60; // 单位：秒。超过 120 会影响文章锁定
    return $settings;
} );

把它存成 wp-content/mu-plugins/heartbeat-limit.php（mu-plugins 文件夹不存在就新建一个），这个文件会自动生效，不用在后台启用，换主题也不会丢。我测试时用的就是 mu-plugin 方式。

60 秒对大多数站来说是稳妥的值。代码里有一行注释写着”文章锁定 150 秒后过期”，所以只要不超过 120 秒，多人编辑时的锁定提醒照样能用。

另外，核心本身已经做了一些节流，你不用再管：标签页切到后台或失去焦点时，心跳自动变成 120 秒一次；鼠标键盘 5 分钟没动静，也会降到 120 秒；在非编辑页面闲置 10 分钟后，心跳会直接暂停。编辑页面关闭了暂停功能，所以写文章的页面开着不管，它会一直跳。

6. 自动保存和修订版本：两个常量各管一件事

写文章时还有一类后台请求是自动保存。从 WordPress 5.1 起，块编辑器也遵守 AUTOSAVE_INTERVAL 常量（Trac #45262）。在 7.1 源码里，这个常量的默认值是 60 秒，edit-form-blocks.php 会把它原样传给编辑器。

我实测时，在新文章里改了内容，默认设置下第 56 秒发出了保存请求；把常量设成 120 后，保存请求推迟到了第 116 秒。只有在有未保存改动时它才会触发，所以影响的主要是长时间编辑的场景：

php

define( 'AUTOSAVE_INTERVAL', 120 ); // 单位：秒

修订版本是另一回事，它影响的是数据库体积。WordPress 默认不限制修订数量，一篇文章改上百次，就存上百份。用下面这个常量限制保留的份数：

php

define( 'WP_POST_REVISIONS', 5 ); // 写 false 则完全关闭修订

这里有个我测出来的细节，很多教程没提。我先让一篇文章攒了 10 份修订，再加上限制为 5 的常量，结果数据库里还是 10 份。直到我再编辑一次那篇文章，才被裁剪成 5 份。也就是说，这个常量不会自动清理历史修订，它只在每篇文章下一次保存时生效。已经堆积的旧修订，要用工具一次清掉，可以参考这篇用 WP-Optimize 清理数据库冗余，清理前记得先备份。

7. 清理过大的自动加载选项

wp_options 表里有一类数据叫自动加载选项，前台和后台每次加载都会一次性把它们全部读进内存。插件删掉了，它留下的设置往往还在，还继续自动加载。

站点健康里有一项专门的检查。7.1 源码里的默认阈值是 800000 字节（约 800KB），超过这个值，检查结果就会变成严重问题，英文标题是 “Autoloaded options could affect performance”。中文后台显示的是对应的译文，意思是”自动加载选项可能影响性能”，并且会给出选项数量和总大小。

想看具体是哪几条最大，可以在 phpMyAdmin 里执行下面这条 SQL。如果你的表前缀不是 wp_，记得改成自己的：

sql

SELECT option_name, LENGTH(option_value) AS size
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto')
ORDER BY size DESC
LIMIT 20;

这四个值来自核心函数 wp_autoload_values_to_autoload()，它是 6.6 新增的。从 6.6 开始，autoload 列除了老的 yes/no，还会出现 on、auto-on、auto 这些值，只查 autoload = 'yes' 会漏掉不少。

找到确认已经没用的大选项（通常是已删除插件留下的）以后，有 WP-CLI 的话可以只关掉它的自动加载，不删除数据：

bash

wp option set-autoload 选项名 off

这条命令我在 WP-CLI 2.12 上测过，执行后数据库里该选项的 autoload 值变成了 off。不认识的选项别动，核心选项更不要碰，操作前先备份数据库。

另外，6.6 起核心自己也加了一道保护：新写入的单个选项超过 150000 字节时，如果插件没有明确要求自动加载，WordPress 默认就不会自动加载它。所以老站更需要做这项检查，新站的问题会少一些。

8. 切断拖慢后台的外部请求

如果第 1 节测出来服务器响应不慢，但页面一直有请求挂着；或者 Query Monitor 的 HTTP API Calls 面板里有耗时很长的外部请求，那就要处理外部连接了。国内服务器连 wordpress.org、gravatar.com 这类境外地址时，经常会遇到这种情况。下面三个办法我都测过。

隐藏仪表盘的 WordPress 活动及新闻模块。 这个模块在后台对应英文的 WordPress Events and News。它会通过 admin-ajax 发出 get-community-events 请求，再由服务器去请求 api.wordpress.org。我测试时，默认状态下打开仪表盘会触发 2 次这个请求。在右上角”显示选项”里取消勾选这个模块后，请求变成 0 次。原因是 dashboard.js 只给可见的模块加载内容。

关闭头像显示。 我测了仪表盘、评论页和用户列表三个页面，开启头像时每页各有 2 个 gravatar.com 请求，关闭后都是 0 个。关闭方法是进入”设置 → 讨论”，在头像区域取消那个控制是否显示头像的勾选框（英文后台叫 Show Avatars）。代价是前台评论区的头像也会一起消失，你自己权衡。

用常量拦截外部 HTTP 请求。 这一招最彻底，也最容易出问题，适合已经用 Query Monitor 查清楚有哪些外部请求的人：

php

define( 'WP_HTTP_BLOCK_EXTERNAL', true );
define( 'WP_ACCESSIBLE_HOSTS', 'wordpress.org,*.wordpress.org' );

我实测了三个地址。example.com 被拦下，返回 “User has blocked requests through HTTP”。api.wordpress.org 正常放行。但如果只写了 *.wordpress.org，不带子域名的 wordpress.org 也会被拦截，因为核心把星号转换成了”至少一个字符”的匹配。所以白名单里两个都要写。

付费插件和主题的授权、更新服务器也必须加进白名单，不然它们会提示授权失败或无法更新。具体有哪些域名，以 Query Monitor 里看到的为准。

9. PHP 版本和 OPcache

PHP 版本对后台速度的影响，比很多人想的要大。WordPress 官方要求页面目前推荐的是 PHP 8.3 或更高版本，数据库推荐 MySQL 8.0 或 MariaDB 10.11 及以上。另外，WordPress 7.0 已经停止支持 PHP 7.2 和 7.3，最低要求是 PHP 7.4。

升级前一定要先确认主题和插件兼容，具体步骤可以看WordPress 升级 PHP 版本的完整教程。

OPcache 是另一个常被忽略的点。它会把编译好的 PHP 代码缓存在内存里，不开的话，每个请求都要重新编译一遍 WordPress。7.0 起，站点健康新增了一项 Opcode cache 检查：如果检测到没开，会显示 “Opcode cache is not enabled”，并标为建议改进。看到这一条，就让主机商帮你开启。用 VPS 的话，在 php.ini 里设置 opcache.enable=1 并重启 PHP。

都做完还慢？问题可能出在主机本身

按顺序做完上面这些，大多数后台慢的问题都能找到原因。如果 Query Monitor 显示查询不多、外部请求也干净，”Waiting for server response” 却还是好几秒，那就得看服务器资源了。共享主机 CPU 被同机用户占满，或者 VPS 配置太低，都会出现这种情况。

可以先对照这篇 CPU 占用率过高的 10 大原因排查，确认是不是资源瓶颈。如果确实是主机扛不住，换一台合适的主机往往比继续折腾优化更省事。我自费测过的几家整理在外贸建站 WordPress 主机推荐里，可以作为参考。

这篇文章里的数据是怎么测出来的

为了让每个结论都能复现，测试环境如下：

• WordPress： 官方 GitHub 镜像的 7.1 分支（7.1.5-alpha，当前正式版为 7.1.4）
• PHP： 8.3.6，memory_limit 设为 128M
• 数据库： 官方 SQLite Database Integration 插件
• 浏览器： 无头 Chromium，用 Playwright 脚本登录后台，记录网络请求
• 测试日期： 2026 年 10 月 31 日

Heartbeat 数据是在编辑器和仪表盘分别停留 65 秒或 130 秒，统计 action=heartbeat 的请求时间点得到的。内存数据是在后台和前台页脚输出 ini_get( 'memory_limit' ) 读出来的。修订、自动加载和 HTTP 拦截则用 WP-CLI 直接调用核心函数验证。

你的服务器环境不同，绝对耗时会不一样，但这些机制层面的结论（哪个参数生效、哪个不生效）是由核心代码决定的，换环境也一样。