HTTP Requests Manager
View on WordPress.orgScores higher than 46% of indexed plugins
About
Limit, Debug, Optimize WP_HTTP requests. Limit by request count, page load time, reduce timeout for each request. Speed up login and admin pages.
What It Does
HTTP Requests Manager gives administrators direct control over the WP_HTTP layer by capping how many outgoing HTTP requests WordPress can make per page load, shortening per-request timeouts, and logging the calls for debugging. In practice, this stops a slow or unresponsive third-party API from stalling your admin dashboard, login page, or front-end while you still get a record of what was requested and where it came from.
Who It's For
This plugin fits WordPress sites that depend on several external services (payment gateways, CRMs, analytics, geolocation lookups, marketing APIs) and need a safety net against slow or failing endpoints. It is also useful for agencies and administrators troubleshooting timeout-heavy admin screens on shared or resource-limited hosting.
Who Should Skip It
If your site makes only a handful of trusted external requests or you do not have the technical confidence to interpret HTTP logs and tune timeouts, this plugin is overkill and may mask real integration problems. Most small blogs and simple brochure sites will not benefit from the added complexity.
The Bottom Line
HTTP Requests Manager is a focused, well-maintained utility that solves one specific problem very well: preventing slow external APIs from dragging down WordPress page loads. With only 1,000 installs and zero public support threads, it is still a relatively niche, developer-oriented choice, so pair it with your own monitoring rather than relying on community troubleshooting. Worth installing if external HTTP calls are a known pain point; skip it if your site is mostly self-contained.
Related Plugins
Pick this if you need a much broader developer console covering database queries, PHP errors, hooks, and HTTP calls, and you can tolerate its higher overhead on production sites.
Choose this when the bottleneck is actually scheduled tasks calling out to remote services rather than synchronous HTTP requests during page loads.
Pick this if your primary concern is slow or failing wp_mail deliveries, which are a very specific subset of WP_HTTP traffic.
Choose this instead only if your performance issue is media delivery size rather than external HTTP latency.
Pick this if you want official WordPress.org performance experiments and broader page-speed tuning rather than a focused HTTP throttling tool.