How to Track External HTTP Requests in WordPress

One of the most common causes of slow WordPress sites is plugins that frequently make HTTP requests to external sources. In this article, we will tell you how to find and eliminate such requests.

External HTTP requests

When it comes to WordPress performance, proper caching is one of the most important things, but unfortunately, not all requests can be cached efficiently. For example, when working with online stores on WordPress, social networks, when using sessions in PHP, and just inside the WordPress administration panel, most requests will go past the page cache.

However, it is important to monitor the speed of such requests, and in addition to working with the database and complex calculations, they are often affected by external HTTP requests, for example, to collect some statistics, to check licenses for themes, and plugins, or for updates.

At the very core of WordPress, checking for updates occurs every 12 hours, and is forced when visiting the “update” page (which is why it sometimes takes so long to load), and this should not affect other sections of the site.

In WordPress themes and plugins

In plugins and themes for WordPress, especially the “premium” type, unfortunately, things are much worse. Some similar products check the license key or collect statistics on every visit to any page, including background and AJAX requests. They do this, of course, using external HTTP requests with functions wp_remote_request()or even worse – curl_exec()or file_get_contents().

Also see: Critical vulnerability in User Role Editor plugin

When these default functions are used, the entire PHP process is blocked until a full response is received from the third party, or after (default) five seconds have elapsed. That is, if the third-party server where the request is made does not respond for any reason, then each view of your site will be five seconds slower.

How to find similar HTTP requests

With the Debug Bar and Debug Bar Remote Requests plugins, you can view requests made while visiting a specific WordPress page:

In this panel, you will see the total number of requests, the total time and time for each request, and, most interestingly, where the function call on the external HTTP request came from. This will give you an idea of ​​which plugin or theme is performing which request.

Please note that you must log in as an administrator, and if you are interested in HTTP requests executed in other contexts, for example, in AJAX requests or in Cron tasks, then you can use the HTTP Logger module in the Core Control plugin, or display information about requests, for example, to the PHP error log using a special event http_api_debug :

add_action( 'http_api_debug', function( $response, $type, $class, $args, $url ) {
error_log( 'URL: ' . var_export( $url, true ) );
error_log( 'Args: ' . var_export( $args, true ) );
// ...
}, 10, 5);

What about curl_exec() and file_get_contents()?

The above plugins and event fire only for those requests that are made using the HTTP API in WordPress, but often theme and plugin authors use third-party frameworks, or write requests themselves using the cURL library directly, the file_get_contents() functions, and others.

Such requests are a little more difficult to catch, but if your hosting provider allows you to use PHP code profiling tools (for example, Xdebug or XHProf), then they will all immediately pop up in the report.

If you are using XHProf, then we recommend that you try saving profiles of all requests to your site that take more than 2 seconds to complete:

// wp-config.php
xhprof_enable( XHPROF_FLAGS_MEMORY | XHPROF_FLAGS_CPU );

register_shutdown_function( function() {
if ( timer_stop() < 2.0 )
return;

$data = xhprof_disable();
file_put_contents( sprintf( '/tmp/profile-%d.xhprof', time() ), serialize( $data ) );
});

Thus, profiles of slow queries will be saved to the /tmp directory on the server, which can be viewed later through the XHProf web interface. With a large amount of traffic and slow requests, the directory may become full of profiles, so do not forget to delete them in a timely manner.

How to eliminate HTTP requests

If you find slow HTTP requests in a plugin, then the easiest way to get rid of it is to get rid of the plugin, but unfortunately, this is not always possible. In this case, we advise you to write to the plugin author about the problem, and for example, temporarily comment out/delete the line that executes the request.

The request can also be temporarily cached using transit :

$key = 'my-slow-request';
$data = get_transient( $key );
if ( false === $data ) {
$r = wp_remote_get( ... );
$data = wp_remote_retrieve_body( $r );
set_transient( $key, $data, 24 * HOUR_IN_SECONDS );
}
// ...

Thus, this slow query will only run once every 24 hours, and for high-load projects, we always recommend running such queries in the background, using the TLC Transients library.

Conclusion

As we mentioned earlier, external HTTP requests are a common but far from the only possible cause of slow WordPress sites.

Performance is also affected by options and transits, complex queries to the database, including search by metadata, proper caching setup and server configuration Nginx/Apache, MySQL/MariaDB, Redis/Memcached, and much more.

If you have any questions about HTTP requests or any questions related to the performance of WordPress, leave a comment and we will definitely answer you.

Leave a comment

Your email address will not be published. Required fields are marked *