自引入WordPress REST API以来,许多插件开发人员已开始将其插件转换为使用REST API而不是较旧的AJAX API(admin-ajax.php
)。除了REST API只是一种较新的技术外,有传言说REST API也比旧的端点更快,更可靠,原因是在典型的REST请求期间没有加载太多的WordPress。
在本文中,我们将研究典型的REST请求以及提出的类似请求admin-ajax.php
以了解它们之间的比较情况。
- 原文来源于:详情

admin-ajax.php请求的寿命
让我们首先分解一下当我们向发出典型的AJAX请求时会发生什么admin-ajax.php
。当您的浏览器对该文件发出请求时,它会加载其他一些核心WordPress文件,以便能够在加载了核心功能的情况下满足请求:
/wp-load.php
/wp-config.php
/wp-settings.php
(它会加载大多数核心文件,所有活动的插件和主题以及REST API)/wp-admin/admin.php
/wp-admin/includes/ajax-actions.php
加载这些文件后,WordPress将调用该admin_init
挂钩,几个核心功能都将挂钩。在WordPress 4.5.3的此钩子上调用了以下核心功能:
register_admin_color_schemes
send_frame_options_header
_wp_check_for_scheduled_split_terms
_wp_admin_bar_init
_maybe_update_core
_maybe_update_plugins
_maybe_update_themes
调用完这些函数后,WordPress最终将调用$_GET[‘action’]
或$_POST[‘action’]
变量中提供的AJAX操作。
REST API请求的生命周期
与admin-ajax.php
请求相比,典型的REST请求看起来略有不同。由于REST端点是由WordPress重写API处理的,因此请求将传递到/index.php
,然后正常加载其余WordPress。
/index.php
/wp-blog-header.php
/wp-load.php
/wp-config.php
/wp-settings.php
(它会加载大多数核心文件,所有活动的插件和主题以及REST API)
与发送过来的请求不同admin-ajax.php
,REST API不会通过加载WordPress管理部分/wp-admin/admin.php
,也不会触发admin_init
动作挂钩。基于此,任何不依赖于管理员特定功能(但使用admin-ajax.php)的插件或主题都可能会通过切换到REST API来获得轻微的性能提升。
基准测试
既然我们已经看到了幕后发生的事情,那么让我们建立一个可以轻松进行基准测试的场景。为此,我们将创建一个可以在admin-ajax.php或REST API上运行的简单函数:
function benchmark_request() {
$result = array( 'time' => time() );
echo json_encode( $result );
exit;
}
add_action( 'wp_ajax_benchmark_request', 'benchmark_request' );
add_action( 'rest_api_init', function() {
register_rest_route( 'benchmark/v1', '/benchmark/', array(
'methods' => 'POST',
'callback' => 'benchmark_request'
) );
} );
上面的函数只是返回JSON中的时间-这只会有助于使您更容易看到请求没有被缓存。
为了执行实际的基准测试,我们将使用ApacheBench,这是一个命令行基准测试工具,它使您可以一次触发多个请求以了解服务器的性能。
让我们admin-ajax.php
先测试版本。
ab -n 100 -c 1 -p ~/Desktop/post.data -g ~/Desktop/ajax.tsv -T application/x-www-form-urlencoded http://localhost/rest-api/wp-admin/admin-ajax.php
上面的命令将100个POST请求发送到该/wp-admin/admin-ajax.php
文件并记录响应时间。post.data
引用的文件只是一个文本文件,其中包含要与请求一起发送的URL编码的$ _POST值(在本例中为action=benchmark_request
)。

在100个请求下,在MAMP和PHP 7上全新安装WordPress且未激活其他插件的情况下,平均响应时间为253ms。这为基于REST API的相同测试提供了良好的基准:
ab -n 100 -c 1 -p ~/Desktop/post.data -g ~/Desktop/rest.tsv -T application/x-www-form-urlencoded http://loc

毫不奇怪,在此比较中,REST API的速度稍快,在100个请求中的平均响应时间为217ms。显然,这并不是一个很大的差异,REST API仅比传统的AJAX API快15%,但是在许多请求中,这种微小的差异肯定会加起来,尤其是当添加了更多插件时。
让我们运行相同的基准测试,但激活一些插件。对于这些测试,我激活了一些常见的插件,您可能会在典型的网站上找到它们:
- ACF
- Akismet
- Black Studio TinyMCE小工具
- WP迁移数据库
- WP超级缓存
- Yoast SEO
尽管总体响应时间有所增加,但admin-ajax.php和REST API之间的性能差距仍然大致相同。随着额外的插件加载,REST API,将约16%的速度,并有一个平均响应时间490ms相比567ms以上admin-ajax.php
:
具有大量插件的网站可以通过REST API看到更大的性能提升,但这完全取决于正在运行哪些插件以及如何对其进行编码。
因此,您应该使用WordPress REST API吗?
从性能的角度来看,显然有一点优势。添加自定义API端点非常简单,并且由于不必加载太多WordPress核心(包括管理区域和常用admin_init
钩子),因此它admin-ajax.php
在大多数情况下可能会比使用更快。
在可靠性方面,REST API仍取决于活动插件或主题的质量和完整性。编码不良的插件仍可能轻易干扰REST请求,尤其是将来有更多插件采用REST API时。但是,由于使用REST API的插件较少,因此目前应该更可靠。
总体而言,至少考虑使用REST API绝对是一个好主意。添加自定义API端点非常简单,并且切换现有代码也不需要很多。