External requests also known as WP_HTTP API calls can happened on any page type in WordPress. See where most external requests are performed and how it affects real user experience.
As a WordPress website admin can you control which page types external API calls can happen?
Let’s learn.
Watch this video on YouTube. (Likes and comments appreciated.)
More WP_HTTP tuning videos can be found in Youtube playlist.
Table of Contents
On which page types External Requests performed?
There is no strictly defined rule regarding where or on which page types external WP_HTTP API calls can be performed.
WordPRess core uses WP_HTTP requests:
- Inside admin pages to check updates, access plugin repository, show plugin info, check browse happy, check serve happy.
- Inside cron to check updates, enclosure checks, send pingbacks, perform website health checks.
- Inside ajax to load oEmbed data, download core and plugin updates.
- On login pages to load WordPress translations.
Plugins also perform External Requests on different page types to load news, check license, load templates, save backups, load analytics, send emails via API etc.
To view External Requests (WP_HTTP API calls) by Page Type I am using “HTTP Requests Manager” plugin.
It records all external requests happening inside WordPress website. You can view those records (logs) and group them by page type where those requests are performed.
Grouping by page type simplifies the report so you can clearly understand where most or slowest external requests are performed.
Here is the list of page types:
- frontend
- admin
- login
- cron
- ajax
- xmlrpc
- rest_api
Why is it important to monitor external requests by page type?
External requests are slow by definition: load or send data by communicating to external servers. Speed of external requests depends on the network and response time of the external server.
For this reason it is not desirable to perform external requests on pages where real users expect instant response.
Pages where users expect fast response (page generation and loading time):
- Frontend (frontend) – this is where the majority of web users and bots will access your WordPress website.
- Login – page where site admin, editors or members login to access admin area.
- Admin – pages where users manage WordPress, content or access member specific areas.
- Xmlrpc – used when WordPress integrated with external applications.
- Ajax and Rest API – should be fast when important and visible parts of the web page loaded dynamically.
From these pages the frontend always should be super fast. Ideally less than 1 second.
Login and admin pages should be less than 3 seconds. If you have a small number of users less than 5 that access the admin area then maximum page generation time should be less than 3 seconds. If you have more users (client , students) then page generation time should be less than 1 second.
Page generation time that are acceptable to be slow:
- Cron – designed to be slow. Most WP_HTTP requests should be performed here.
- Ajax and Rest API – can be slow when used to perform background operation that does not generate response to the user.
From all these page types “frontend” pages should be always fast. Meaning less WP_HTTP requests on frontend.
Page type that can be slow is “Cron”. Meaning can handle slow and multiple WP_HTTP requests without problem.
Control external requests by page type
The frontend should always be fast. So why not block all WP_HTTP requests on the front end?
Because WP_HTTP requests are used to initiate cron jobs as well. If we block all WP_HTTP requests we will reduce and delay execution of periodically cron jobs.
Instead of blocking all requests identify requests by plugin or domain that are performed on the frontend.
When you detect non-essential WP_HTTP requests there then you can block them by domain or plugin with custom rule for frontend.
This is a more precise way of blocking without affecting cron job execution.
Recommendation for plugin developers
Best practices for plugin/theme developers that use WP_HTTP API calls in their code:
- Use WP_HTTP requests only inside cron jobs.
- Limit to maximum 3 WP_HTTP requests per page.
- Have some resting time between request batches. For example if you need to do 10 WP_HTTP requests. Do 3 requests on each cron job and wait between cron jobs 1 minute.
- Prefer non blocking WP_HTTP requests when possible. For example when only sending some data to a remote server.
- Cache WP_HTTP response in transients.
- Double check if periodic WP_HTTP requests run only once for a defined period regardless of success or failure. For example if a request is defined to run once per 24 hours make sure that it runs once even when request fails or blocked.
- Test plugin with WordPress website where all external WP_HTTP requests are blocked.
- Optimize WP_HTTP usage because it can slow down your plugin. WordPress website owners mostly prefer a faster plugin.
Use the HTTP Requests Manager plugin to see WP_HTTP requests in cron jobs. The Query Monitor plugin can’t show these requests in cron jobs. Understand the differences between these plugins when debugging WP_HTTP API calls
Conclusion
Viewing WP_HTTP requests (API calls) by page type makes it easy to understand what users experience when they use your WordPress website.
When you detect that WP_HTTP usage slows down WordPress website you can either block related requests and improve performance of your website.
Additionally you can contact related plugin developers via plugin support forum on WordPress website. Plugin developers are generally motivated to improve their plugins and will implement your recommendations. Improving WP_HTTP usage by plugin developers will improve performance of all websites that use related plugins.
I have contacted multiple plugin developers regarding issues related to WP_HTTP usage via the support forum and most of them optimized their plugins.
What is next:
- Download HTTP Requests Manager plugin
- Learn to debug WP_HTTP usage with case studies.
- Block or Allow WP_HTTP requests using custom rules.
- Learn how “Smart Block” mode optimizes WP_HTTP usage.