Block Slow Outbound HTTP Calls in wp-admin
Available since 6.29.30.
Plugins and themes make outbound HTTP requests while wp-admin pages render: licence checks, update checks, telemetry and marketing feeds. Each one is a synchronous call, so WordPress waits for it before it finishes building the page. If the endpoint is slow or unreachable, that wait is added to every admin page that makes the call, and it’s rarely your own code at fault.
Scalability Pro’s HTTP API tab lets you block specific endpoints, one rule at a time. Outbound requests are allowed by default. With no rules configured, the only thing the tab does is stop unrelated third-party calls while Scalability Pro’s own settings page renders.
The delay is worst when an endpoint is unreachable rather than merely slow. A refused or dropped connection can sit waiting for the full HTTP timeout, often several seconds, on every admin page that makes the call.
Adding a rule
Each rule has four fields:
| Field | What it does |
|---|---|
| URL wildcard | The outbound URL to block, for example *api.freemius.com/v1/installs/*. * is the only wildcard |
| Owning plugin slug | The rule is skipped on that plugin’s own admin pages, so its settings screen keeps working |
| Purpose | Licence, update, telemetry, marketing or other. A label for your own reference |
| Allowed admin page wildcards | Extra admin pages, one per line, where the rule does not apply, for example *page=my-plugin* |
A rule needs a concrete host. Catch-all patterns are rejected when you save, and you can store up to 100 rules.
A blocked call returns a normal WordPress HTTP error to the plugin that made it, so the plugin sees a failed request straight away instead of waiting. If Query Monitor is active, it logs a debug line naming the blocked URL.
Finding which calls to block
You don’t need to guess. Run an analysis with the free Super Speedy Performance Analysis plugin, then click Review latest analysis on the HTTP API tab. Scalability Pro reads the newest completed run and lists its slow outbound calls as suggested rules, each with the measured time, the plugin responsible and a suggested URL wildcard. Nothing is read until you click the button.
Review every suggestion before adding it. Classification is cautious, but only you know whether a licence or update check matters to your site.
Where a rule never applies
The rules only affect admin pages being rendered. These boundaries are enforced in code:
- Front end, REST, cron and AJAX requests: rules are skipped entirely, so visitors and checkout are never affected.
- Form submissions: rules only apply to GET and HEAD admin requests, never to a save or any other change.
- Plugin, theme and update screens: always allowed, so updates keep working.
- WooCommerce screens: orders, settings, payments, checkout and refund screens are always allowed.
- Payment providers: a built-in list of 22 payment gateway domains, including Stripe, PayPal, Braintree, Square, Mollie and Klarna, can never be blocked. Payment calls appear in the analysis suggestions but cannot be added as rules.
- Your own site: requests back to the same host and port are untouched.
Blocking a licence check on a plugin’s own settings page can stop that plugin activating or showing its licence status. Fill in the Owning plugin slug so the rule steps aside on that plugin’s pages.
Comments