1

By using Query Monitor I'm finding that virtually every page load within Wordpress admin results in 15-25 server-side HTTP API calls being made. Most take less than 0.1s, but there's 5 or more that take 0.3 to 0.4s. Overall it's slowing down page load times by 3s or so.

These requests seem to mostly be to 3rd party sites licensing, version-check or authentication APIs.

For example, one is to Woocommerce - https://api.wordpress.org/plugins/info/1.0/woocommerce.json

Some others include:

(Some of these are POST requests so won't provide anything useful if you go the URL directly without the POST data)

The Facebook for Woocommerce plugin makes 4 calls to facebook.com APIs which take around 1s collectively on their own.

These requests are occurring on pages within the admin which seemingly have nothing to do with these plugins. There's at least 10 plugins doing a similar thing. Most are really well known and popular plugins (e.g. Yoast and WP-Rocket to name a couple more).

Is this normal? It seems crazy to me that licensing checks, version updates, pricing tables, etc, would be happening on virtually every page load within the admin.

Is there any way to stop these without modifying plugin code?

Thanks!

6
  • You could likely stop these with some code, but since third party plugins are off topic here you'd need to ask the plugin authors or support community what the appropriate code is, and whether this is normal. Jul 19 at 2:01
  • @JacobPeattie I appreciate that it's related to third party plugins, but I think it's a discussion in broader terms with regard to whether it's normal. It's happening across many of the most popular plugins. Is this a Wordpress design flaw? Are others just dealing with it and accepting that their admin page loads are slowed down by this kind of behaviour from plugins? I kind of feel like I'm going mad as it just seems crazy to me and I can't really find anyone else that's talked about it online.
    – Baraka
    Jul 19 at 8:24
  • if on every admin page load you get 15-25 externak HTTP requests, there is something very wrong with your plugins. Frankly it is more likely that either you do not look at the right data, or there is some additional setting or interaction which make the plugins behave weird Jul 22 at 10:05
  • @MarkKaplun Yep turns out it's not normal. It's now back to doing only 1 or 2 requests and only on some pages / intermittently. I'm guessing it's because transients were broken in some way. Another dev recently resolved some issues with external object cache, which I wasn't aware of. It makes sense as most of the requests I see now are aligned with the transient updates made by the page. Unfortunately this was marked as off-topic, which I don't believe it is. Prob because a mod thinks its related to 3rd party plugins, when really the question was about normal behaviour, which you've answered.
    – Baraka
    Jul 22 at 14:29
  • it is off-topic because it is either a plugin problem or something in your local setting. In both cases it is hard to give an answer without having access to the code and/or the server. I could have guessed it is something to do with transients, but that would not have been an answer just a guess ;) Jul 22 at 17:18

1 Answer 1

2

You can block/allow external requests if you like, using a combination of WP_HTTP_BLOCK_EXTERNAL and WP_ACCESSIBLE_HOSTS. Here is the note from /wp-includes/class-http.php:

/**
 * Block requests through the proxy.
 *
 * Those who are behind a proxy and want to prevent access to certain hosts may do so. This will
 * prevent plugins from working and core functionality, if you don't include api.wordpress.org.
 *
 * You block external URL requests by defining WP_HTTP_BLOCK_EXTERNAL as true in your wp-config.php
 * file and this will only allow localhost and your site to make requests. The constant
 * WP_ACCESSIBLE_HOSTS will allow additional hosts to go through for requests. The format of the
 * WP_ACCESSIBLE_HOSTS constant is a comma separated list of hostnames to allow, wildcard domains
 * are supported, eg *.wordpress.org will allow for all subdomains of wordpress.org to be contacted.
 *
 * @since 2.8.0
 * @link https://core.trac.wordpress.org/ticket/8927 Allow preventing external requests.
 * @link https://core.trac.wordpress.org/ticket/14636 Allow wildcard domains in WP_ACCESSIBLE_HOSTS
 *
 * @staticvar array|null $accessible_hosts
 * @staticvar array      $wildcard_regex
 *
 * @param string $uri URI of url.
 * @return bool True to block, false to allow.
 */

So if you want to speed things up by disallowing these API calls on most admin pageloads, you could block thing if not on the dashboard with something like this (as an mu-plugin?) - so that licenses do get checked on the dashboard. (But there are also plugin settings pages and AJAX/REST requests to allow for.) Experimentally:

add_action( 'muplugins_loaded', 'block_external_if_not_dashboard' );
function block_external_if_not_dashboard() {

    /* bug out conditions */
    if ( wp_doing_ajax() ) {return;}
    if ( defined( 'REST_REQUEST' ) && REST_REQUEST ) {return;}
    if ( !is_admin() ) {return;}
    if ( isset( $_REQUEST['page'] ) ) {return;}
    if ( '/wp-admin/' === substr( $_SERVER['REQUEST_URI'], -10, 10 ) ) {return;}

    /* block access to external HTTP requests */
    if ( !defined( 'WP_HTTP_BLOCK_EXTERNAL' ) && !defined( 'WP_ACCESSIBLE_HOSTS' ) ) {
        define( 'WP_HTTP_BLOCK_EXTERNAL', true );
        define( 'WP_ACCESSIBLE_HOSTS', 'api.wordpress.org' );
    }
}

Of course, there's no guaranteeing this won't affect some plugins, so if they malfunction you'd need to add their hosts to the list in WP_ACCESSIBLE_HOSTS

2
  • Thanks for this! Works well but some adjustments necessary. The function is wp_doing_ajax() not wp_is_doing_ajax(). The majority of the requests still executed, because "current_screen" triggers too late. I updated the action to "muplugins_loaded". This also means get_current_screen() doesn't work, so I removed that section and added if(!is_admin()) return; Will probably need to optimise the if statements over time so it can load on some of the admin pages but not others.
    – Baraka
    Jul 20 at 15:39
  • @Baraka Cool! I updated it with those improvements, and added a match for the dashboard via the request URL instead of current screen... the check for $_REQUEST['page'] should mean that most plugin admin pages should work too. But yes, it may need extra tweaking over time.
    – majick
    Jul 22 at 1:23

Not the answer you're looking for? Browse other questions tagged or ask your own question.