前台打开很快，后台点一次“文章”却等好几秒，未必是服务器整体性能不足。前台可能命中了页面缓存，后台登录态页面通常仍需要运行 PHP、查询数据库，并加载编辑器和插件脚本。先找出慢的是后台页面本身，还是页面打开后的某个异步请求；把这两件事混在一起，容易误把 Heartbeat 当成唯一原因。
下面以有权维护的网站为前提，按“记录现象、定位请求、排查插件与数据库、复测”的顺序检查。改插件配置或数据库前先备份，并尽量在预发布环境复现。
先确定慢在哪里
用同一个管理员账号，分别打开“仪表盘”“文章列表”和“编辑文章”，记录哪一步慢、持续多久、是否只有某个账号或编辑器页面慢。再用浏览器开发者工具打开 Network，勾选保留日志，刷新后台页面，按耗时排序：
- 主文档请求就慢：重点看服务器响应等待时间、PHP 执行、数据库、对象缓存与外部 HTTP 调用。
- 主文档很快，后续请求拖住界面：筛选 Fetch/XHR，查看慢请求的路径、
action参数和响应状态；admin-ajax.php是入口，不能仅凭文件名认定是 Heartbeat。 - 网络请求结束后仍操作卡顿：查看浏览器 Performance 面板中的长任务，并检查编辑器脚本或浏览器扩展；此时继续调数据库未必有帮助。
最好分别记录第一次加载和重复加载、正常时段与高峰时段的结果。前台正常也要用登录状态下的未缓存页面对比，避免把缓存带来的速度差误判为后台专属故障。
admin-ajax.php 多，不等于 Heartbeat 出了问题
WordPress 的 Heartbeat API 会按间隔向服务器发请求，用于编辑状态等近实时交互。官方文档说明其客户端 tick 间隔可处在 15 至 120 秒范围内，服务端通过 admin-ajax.php 处理。一个后台页面开着不动仍有周期性请求，属于需要结合耗时判断的现象，不能把请求数量直接当成故障。参考：WordPress Heartbeat API。
在 Network 里点开 admin-ajax.php 请求，查看表单数据中的 action。若是 heartbeat，再看单次请求用了多久、响应大小、是否出现 500/502/504、是否随打开的后台标签页数量增加而变慢。如果 action 是插件自定义值，则应先调查对应插件，调整 Heartbeat 间隔不会消除它的请求。
只有在确认 Heartbeat 请求频繁、单次执行昂贵且确实影响后台响应后，才考虑通过受支持的设置调低频率。修改后检查文章自动保存、多人编辑锁定和通知等实际依赖功能；不要直接全站禁用 Heartbeat。WordPress 提供 heartbeat_settings 过滤器，但具体调整需结合插件、编辑器和当前站点行为验证。参考：Heartbeat 设置过滤器。
插件请求慢：定位到插件，再做可回滚的隔离
同样是 admin-ajax.php，插件可能借它执行统计、表单、备份进度或远程接口检查；编辑器也可能请求 REST API。先记录慢请求的 action、发起脚本、响应码和响应内容，再去插件设置或代码里确认是谁发起。若后台一直在转圈，别只盯着最后一个请求：一个失败并反复重试的脚本也会让界面看起来很慢。
具备维护权限时，可在预发布环境使用 Query Monitor 查看数据库查询、HTTP API 调用、PHP 错误和相关组件；它是诊断工具，不应长期把调试面板暴露在生产环境。参考：Query Monitor 插件说明。
隔离插件应一次只改一个变量：先备份当前启用列表，再暂时停用可疑插件或关闭其具体功能，重复同一后台操作三次；若改善，再启用复现。电子商务、登录、安全与缓存插件可能影响支付或访问控制，生产站应在低峰期操作，并准备恢复原配置。若停用插件也无变化，继续看 PHP 错误日志、数据库慢查询及服务器资源，不要批量停用后就把“变快”归因于最后一个插件。
WordPress 官方建议在修改前使用预发布环境或先备份；调试日志更适合短时间在受控环境启用。WP_DEBUG_LOG 可记录 AJAX 中发生的 PHP 错误，WP_DEBUG_DISPLAY 应关闭；排查结束后关闭调试并保护日志，避免在公网暴露敏感信息。参考：WordPress 调试说明。
autoload 过大：先确认体积和归属，再决定是否调整
WordPress 会加载标记为 autoload 的选项并缓存。若插件把大量很少使用的数据塞进自动加载选项，后台每次请求都可能多带一份负担。后台“工具 → 站点健康”会提示 autoload 相关问题；WordPress 的默认告警阈值是总量 800,000 字节，这个阈值是排查线索，不等于超出就能断定它是唯一瓶颈。参考：站点健康源码说明。
安装了 WP-CLI 的站点，可以在正确的网站目录中只读查看总量与条目。以下命令适用于已安装并能连接当前 WordPress 的 WP-CLI，具体路径和多站点参数需按实际环境指定：
wp option list --autoload=on --format=total_bytes
wp option list --autoload=on --fields=option_name,size_bytes --format=csv
先找体积明显偏大的选项，查它属于哪个仍在使用的插件或主题、是否每次请求都需要。WordPress 6.6 起，autoload 数据库值已不止 yes/no，还可能有 on、auto、auto-on 等；用 WHERE autoload = 'yes' 的旧 SQL 统计可能漏算。优先使用 WP-CLI 和 WordPress API，不要复制网上的 DELETE FROM wp_options 或批量 UPDATE 清理脚本。参考：WordPress 6.6 Options API 变更及 WP-CLI option list。
确认某个选项只在偶尔打开的插件后台页使用后，先备份数据库，联系插件作者或在预发布环境用 WordPress 的 wp_set_option_autoload() 调整，并测试插件设置、定时任务和前后台功能。**不要仅凭选项名字或大小删除它，也不要改动不清楚用途的 WordPress 核心选项。**参考：wp_set_option_autoload()。
排查后怎样确认真的修好了
回到最初最慢的三个操作，用相同账号、同一网络、相近负载各重复几次。记录后台主文档响应时间、最慢的 XHR/Fetch 请求、PHP 错误数量和站点健康的 autoload 总量。若只是关闭浏览器扩展后变快，就把结论限定为浏览器侧；若某个插件请求的耗时消失且重新启用后复现，再处理该插件的配置或联系开发者。
Heartbeat 请求正常但后台仍慢时，应继续检查 PHP 工作进程是否排队、数据库是否存在慢查询、对象缓存是否生效，以及插件是否发起阻塞性的外部 HTTP 请求。不要在没有证据时把 Heartbeat、autoload 和数据库三项一起修改，否则即使后台变快也难以判断哪个改动有效，更难回滚。
参考资料
- WordPress Developer Resources：Heartbeat API
- WordPress Developer Resources：heartbeat_settings
- WordPress Developer Resources：Optimization / Autoloaded Options
- WordPress Developer Resources：WP_Site_Health::get_test_autoloaded_options()
- Make WordPress Core：Options API: Disabling autoload for large options
- WordPress Developer Resources：WP-CLI option list
- WordPress Developer Resources：wp_set_option_autoload()
- WordPress Developer Resources：Debugging in WordPress
- WordPress.org：Query Monitor
资料核验日期：2026 年 9 月 22 日。