如果你正在编辑一篇长文，WordPress 编辑器每隔几秒就转一次圈，保存草稿要等三四秒才响应，列表页翻页也明显变慢——这种后台卡顿大多不是主机的“性能不行”，而是 admin-ajax.php 在被高频请求拖垮。本文会教你如何一步步定位是哪个组件在疯狂发请求，以及为什么对 Heartbeat API（WordPress 后台的实时心跳机制）做频率控制，通常就能解决大部分后台卡顿问题。整个过程不需要写代码，用浏览器自带的开发者工具加上几个配置片段就能完成。
卡顿的第一现场：admin-ajax.php 为什么会被拖垮
admin-ajax.php 是 WordPress 后台所有异步请求的统一入口。编辑器自动保存、文章列表的快速编辑、评论的实时计数、不少插件的实时通知，全都走这一个文件。它的特点是每个请求都要完整加载 WordPress 核心，也就是说，一次心跳请求的成本并不比刷新一个后台页面低多少。
Heartbeat API 默认的行为是：后台页面获得焦点时每 15 秒发一次 POST 请求到 admin-ajax.php，页面失焦时降到每 60 秒一次。看起来不频繁，但它是叠加的——如果你在后台开了 5 个标签页，就相当于每 15 秒有 5 个请求同时压到服务器上。在共享虚拟主机上，PHP 进程数本来就有限（很多入门方案只允许 2-4 个并发进程），几个标签页的心跳请求加上插件各自的轮询，PHP 进程很快就被占满，后面的请求只能排队，于是你看到的就是“整个后台都在转圈”。
有一个明显的判断信号：如果卡顿只发生在后台、前台页面速度正常，大概率就是 admin-ajax 请求堆积；如果前台也慢，那就要先去排查缓存和数据库。这两种情况的处理路径完全不同，先分清能少走很多弯路。前台慢的场景我们之前整理过一份 WordPress 速度优化实战指南，可以先按那份清单过一遍再做后台排查。
第一步：用浏览器开发者工具找出谁在发请求
排查不需要装任何东西，打开卡顿的后台页面，按 F12 打开开发者工具，切到 Network（网络）标签，在过滤框里输入 admin-ajax，然后让页面保持打开两三分钟。
这时你会看到一列请求，重点看三个信息：
- Time 列：单个请求耗时。正常的心跳请求应该在 100-300ms 内返回；如果 consistently 超过 1 秒甚至 3 秒，说明服务器处理这个请求本身就很吃力。
- 请求频率：数一下一分钟内出现了几次。超过每分钟 4-5 次，就说明有组件在“超额心跳”，Heartbeat API 默认不会这么密。
- 发起者（Initiator）：点击请求后看 Initiator 列，能定位到是哪个 JS 文件发出的。如果发起者不是
heartbeat.min.js而是某个插件的脚本，那问题就找到了。
一个真实场景：某外贸站后台每分钟出现 12 次 admin-ajax 请求，查看 Initiator 后发现其中 8 次来自一个“实时订单通知”插件，其余 4 次才是 Heartbeat 本身。停用该插件后，后台保存草稿的响应时间从 4 秒回到 1 秒以内，服务器负载从 1.8 降到 0.4。
如果 Initiator 指向的脚本看不出属于哪个插件，可以再切到 Console 标签看有没有报错，或者进入插件的 JS 源码里搜索 admin-ajax 关键字，通常能直接看到是哪段代码在轮询。
第二步：限制 Heartbeat API 的频率
确认心跳本身占了大头之后，最直接的手段就是降频。把下面这段代码放进当前主题目录下的 functions.php 末尾（或者用 Code Snippets 这类插件挂载）：
// Heartbeat API 降频：前台 60 秒一次，后台 60 秒一次，编辑器保持 30 秒
add_filter('heartbeat_settings', function ($settings) {
$settings['interval'] = 60; // 全局最低频率（秒）
return $settings;
});
add_filter('heartbeat_settings', function ($settings) {
if (isset($settings['screen_id']) && $settings['screen_id'] === 'post') {
$settings['interval'] = 30; // 编辑页保留 30 秒，保证自动保存
}
return $settings;
});
改完之后清一遍缓存再回到后台，开发者工具里应该能看到心跳请求从每 15 秒一次降到每 60 秒一次。需要注意的是，编辑页的自动保存依赖心跳，把编辑器场景压得太狠（比如低于 30 秒）会导致草稿保存变慢，所以上面这段代码对编辑页单独保留了 30 秒的节奏。
如果你的服务器装了 WP-CLI（命令行管理工具），也可以不碰主题代码，直接用一条命令验证改动的效果：
# 在服务器上执行，统计最近 100 条访问日志里 admin-ajax 的分布
grep "admin-ajax.php" /var/log/nginx/access.log | tail -100 | awk '{print $4}' | cut -d: -f4 | sort | uniq -c
降频后重新跑一遍这条命令，每分钟的请求数应该明显下降。这个方法适合在改代码前后各跑一次，用数据确认而不是凭感觉。
第三步：当降频不够时，逐个排查插件的轮询行为
有些插件不走 Heartbeat，而是自己写了一套轮询逻辑，直接往 admin-ajax.php 发自定义 action。这类请求在开发者工具里表现为：请求体（Payload）里带着 action=xxx 的自定义参数，频率却远高于心跳的节奏。对这类插件，逐个停用是最有效的定位方式——在开发或低峰时段，停用一个插件后观察 Network 里的请求密度，两分钟内没有变化就换下一个，直到请求次数回到正常水位。
停用排查时有一个实用技巧：优先怀疑那些宣传“实时统计”“在线客服”“安全扫描”“销售通知”功能的插件，它们的实现方式几乎都依赖定时轮询。如果某个插件确实需要保留，可以去它的设置页找“刷新间隔”“实时模式”之类的选项，把轮询周期从默认的 30 秒改到 5 分钟，效果往往比停用更现实。判断插件本身是否健康，可以参考这篇 WordPress 插件冲突与白屏排查，里面的逐个停用流程和这里是同一套思路。
插件排查之外，还有两类容易被忽略的卡顿来源值得顺手确认。一是 PHP 版本：仍在跑 PHP 7.x 的站点，同样代码在 8.1 上的请求处理速度通常能快 30% 以上，在主机控制面板里切换 PHP 版本是零成本的优化。二是对象缓存：如果每次心跳都要完整查一遍数据库，安装 Redis 或 Memcached 让重复查询走内存，单个 admin-ajax 请求的耗时会明显缩短。WordPress 自带的定时任务 WP-Cron 也走同样的入口触发，访问量大的站点把它改由系统定时器接管，能进一步减少后台的隐性请求。
第四步：修改后如何验证卡顿真正解决
改动完成后，不要只凭“感觉变快了”。用同一套指标重新测一遍（性能数据随插件数量、主题和主机方案变化很大，下面的数字以 2026 年主流共享主机环境为参考，实际请以你自己站点的测量结果为准）：
- Network 里
admin-ajax的请求频率，对比修改前的截图； - 单个心跳请求的 Time 值，目标是稳定在 500ms 以内；
- 打开文章编辑器连续输入 5 分钟，自动保存是否还会打断输入；
- 服务器控制面板里的 CPU/进程占用，对比降频前后的变化。
四项里至少三项改善，才算这次排查真正闭环。如果请求频率已经降到正常水位、单个请求耗时也在 500ms 以内，但后台依然卡，那问题大概率不在 admin-ajax，而是在数据库慢查询或主机资源上限上——这时可以参考我们之前写过的 WordPress 数据库优化指南，把慢查询这条线也排查一遍。
总结：把心跳控制在合理区间，后台才能保持流畅
回顾整个排查路径：先用开发者工具确认 admin-ajax 请求的频率和发起者，再用 heartbeat_settings 过滤器把心跳降到 30-60 秒一档，然后清理插件里自带的轮询逻辑，最后用前后数据对比验证效果。这四步覆盖了 WordPress 后台卡顿的绝大多数成因，而且全程不需要升级主机配置。如果验证阶段发现单请求耗时始终降不下来，可以接着做 WordPress 慢查询数据库清理，把数据库这条隐藏拖累也处理掉。
如果你按上面的步骤处理后，心跳请求已经正常、插件也排查过了，后台在高峰期仍然吃力，那么可以考虑把站点迁移到资源上限更高的环境。我们建议的做法是先在 Hostease 虚拟主机方案上对比一下 PHP 并发进程数和 PHP 版本支持情况——后台体验这类问题，很多时候不是代码优化能解决，而是主机方案的并发上限决定了天花板。如果你需要，Hostease 中文站的技术支持也可以帮你直接检查当前账号的 PHP 进程限制，判断升级是否真的必要。