In today’s fast-paced world, website speed is crucial. A slow website can lead to frustrated users who bounce off quickly, harming your user experience and SEO ranking. WordPress, while powerful, can sometimes be slowed down by core functionalities like WP_HTTP.
This article discusses WP_HTTP, its impact on speed, and how HTTP Requests Manager plugin helps optimize WP_HTTP calls in WordPress.
I will show expected performance improvement for different optimizations and screenshot from logged reports.
Table of Contents
What is WP_HTTP?
WP_HTTP is a built-in functionality in WordPress that allows it to make requests to internal and external servers. These requests are essential for various tasks, such as fetching data from external APIs, checking for plugin updates, or verifying licenses.
Detailed examples using some common WP_HTTP requests are explained in this article.
How Does WP_HTTP Affect WordPress Speed?
Each time WP_HTTP makes a request, it adds to the overall page generation time. Several factors can slow down these requests, such as slow external servers or a high number of concurrent requests.
The longer it takes for these requests to complete, the slower your website loads. Slow loading times can significantly hurt your website’s performance, leading to higher bounce rates and lower search engine rankings.
WordPress websites are dynamic, meaning they build the page you see each time you visit. This process takes time, and if it involves a lot of external requests (WP_HTTP), it can slow down your website.
HTTP Requests Manager Plugin: Optimizing WP_HTTP Usage
HTTP Requests Manager plugin addresses this challenge by optimizing the way WordPress utilizes WP_HTTP. It helps reduce unnecessary requests and streamline essential ones, leading to faster page generation and website loading times.
Here’s how HTTP Requests Manager plugin achieves this in “Smart Block” operation mode.
Example 1: Block Unnecessary Update Checks
WordPress website makes frequent requests to WordPress.org servers to check for updates. This can be a significant source of slowdowns.
On a single page it will make 4-5 different requests to check for updates and translations for WordPress core, plugins and themes installed on your website. This will add to your page generation time around 4 seconds. Total time can reach 5-10 seconds. In rare cases you will see 503 response code meaning your website is not available.
When is this triggered?
Every 12 hours when you first login to the admin panel it checks for updates.
Right after updating or installing a new plugin it checks for other updates.
Viewing plugins page.
Periodically via cron jobs.
Solution
HTTP Requests Manager Plugin tackles this by blocking update checks on slow pages. Updates will be checked on faster pages.
It will not limit update checks in cron jobs. Because cron is designed to handle slow periodic processes like update checks. This way you will always have fast pages and on time updates.
With this optimization WordPress will still check for updates couple times per day.
Quantifiable Improvement: Our tests show that by blocking unnecessary update checks, this plugin can reduce page load times by 2-5 times.
Example 2: Block Browse Happy Checks
WordPress sometimes checks your browser version in order to make sure that the admin interface works correctly. It sends your user agent information to WordPress servers for detecting it. In case you are not using a modern browser it will show you a warning message and suggest updating your browser.
It was useful in 2005 when there were still some users using old Internet Explorer.
In today’s reality most people are already using modern browsers and there is no need for checking it with a remote WP_HTTP request.
When is this triggered?
Every time when you load WordPress admin dashboard. Results are stored for one week. Every browser name and version combination will be considered different. This means hundreds of requests will be made to detect user browsers every week.
Your browser information like this one will be sent to WordPress servers:
“useragent”: “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36”
Solution
Browser version checks with Browse Happy remote requests will be blocked in “Smart block” mode. You do not need them. WordPress operation is not dependent on it.
Quantifiable Improvement: You will save a couple seconds from total page generation time when these requests are blocked.
Example 3: Block enclosure checks
WordPress performs multiple operations when a post or page is saved. One of them is checking all links (including image URLs) for audio and video files.
Problem is in needless mass check for obvious non audio/video file URLs.
In most cases found media file names stored in the database and not used by WordPress.
When is this triggered?
Every time we hit the save button on the post editing page.
For example we generally add around 20 links (internal + external) and 20-30 images in blog posts. This will mean 50 WP_HTTP requests will be performed.
When editing posts we save multiple times to store changes we have made. So it can be 20 saves per document and 50 requests will reach 1000 needless WP_HTTP requests.
Enclosure checks are generally initiated inside WordPress cron jobs.
Solution
HTTP requests manager plugin checks extension of URL strings and blocks non audio/video extensions.
Audio extensions are mp3, wav, ogg etc. Video extensions are avi, mp4, mpeg, gp3 etc.
Blog posts mostly have links to web pages and URLs of added image files like jpg, png, gif, webp.
Check this screenshot comparing “Smart block” versus “Only log HTTP requests” operation mode.
Report is generated when I save an article about WordPress performance optimization that I wrote some time ago. Smart block prevented 54 enclosure checks.
Quantifiable Improvement: Average blog post saving process will speed up 3.9 times. From 15 seconds to 4 seconds.
Plugin will speed up further when logging is switched off.
Example 4: Block self pings
Ping is used to inform linked content that you have mentioned in your blog post. This automation can be abused by adding spam links to many blogs. For this reason it is not used any more. But still WordPress has this feature which can be disabled in settings.
Self pings are when you send pings to your own website following an internal link in your post content. Which is a waste of WP_HTTP request resources.
When is this triggered?
Every time you save a blog post pings will be sent to every link and image URL in your content.
If you have 20 links and 30 images inside post content then 50 ping requests will be sent. In combination with enclosure checks WordPress will send 100 requests inside a single page load using WP_HTTP.
Pings are generally sent inside WordPress cron jobs.
Ping, pingback and trackback are all the same thing.
Solution
Best solution is to completely disable WordPress pings. You do not need to send pingbacks to internal or external URLs.
Pingbacks are mostly used by spammers.
How to disable pingbacks in WordPress?
- Navigate to the “Settings” → “Discussion” page.
- Uncheck both “Attempt to notify any blogs linked to from the post” and “Allow link notifications from other blogs (pingbacks and trackbacks) on new posts” options.
- Save settings.
First checkbox disables sending pingbacks. Second checkbox disables getting pingbacks. You need to uncheck both of them and save settings.
Disabling pingbacks is also one of the best optimization tips for WordPress.
Alternatively HTTP Requests Manager plugin will prevent ping requests sent from your website back to the same website in “Smart Block” operation mode.
Quantifiable Improvement: On average you can expect to prevent 10-30 self-pings per page save action.
Example 5: Block Requests on Slow Pages
WP_HTTP request speed depends on the network and remote server. So in order to keep your WordPress pages fast we need to limit remote requests by total page generation time. This should keep your web pages fast.
When is this triggered?
WP_HTTP requests can happen on any page. Pages interacted by users like frontend, admin and ajax should always be fast.
Solution
HTTP requests manager plugin in “smart block” mode keeps track of page runtime. When the page takes longer than 3 seconds, the plugin will block further remote requests.
Check this screenshot to see how WP_HTTP requests are blocked because the page is already running for more than 8 seconds.
This rule will not apply in following cases:
- Cron pages are designed to handle long and slow tasks. WP_HTTP requests can be long and slow. For this reason the page generation time limit is not applied on cron pages.
- Downloading WordPress updates and plugins is also a slow task. File downloads performed using WP_HTTP requests. Those requests will not be blocked by this 3 second page generation rule.
Quantifiable Improvement: You will see less server timeouts on important pages like WordPress admin dashboard or frontend. Server crashes will be close to 0 as well. Slow pages will be generated faster without additional impact of WP_HTTP requests.
Example 6: Allow maximum 3 requests per page
Multiple WP_HTTP requests can be made on a single page. There is no limit defined by WordPress.
Can you imagine how crazy this is?
I have seen pages with 125 WP_HTTP requests. You can recreate it yourself by following these steps.
- Enable pingbacks in WordPress “Settings” → “Discussion”.
- Install and activate HTTP Requests Manager plugin from WordPress repository.
- In plugin settings select “Only Log HTTP requests” operation mode. This is needed to record and count the number of requests.
- Find blog posts with 50+ links and images combined. All URLs should be unique. Click edit and then save it without any changes.
- Go to “Tools” → “HTTP Requests Manager” plugin.
- There you will see latest requests. Click one of them and on opened window switch to “Check point” tab. You will see all requests made on that single page. Count it there should be more than 100 requests.
When is this triggered?
Having multiple remote requests can happen on any page any time. There is no limitation set by WordPress.
Solution
HTTP Requests Manager plugin in “Smart block” operation mode limits the total number of WP_HTTP requests to 3. Requests initiated after that will be blocked.
You can see from the screenshot above that requests from 5 to 8 were blocked because 3 requests were already used on that page.
Blocking by number of requests will not be applied in cron pages. Because cron is designed to handle important operations even if they take a long time to complete like multiple remote requests.
Quantifiable Improvement: Depending on the original number of requests you can get from 2 to 10 times more improvement. For example if a page has 10 requests only the first 3 of them will be allowed.
Example 7: Reduce timeout for WP_HTTP request
Remote requests have a timeout period. It is used to define how long your WordPress will wait until it gets a response from a WP_HTTP request. Default value is 5 seconds.
Sometimes WordPress can increase this number to make sure that it gets a response.
In order to keep WordPress pages fast we need to set timeout to minimum. Check the difference when “Smart block” is applied and request timeout property reduced to 2 seconds.
In most cases to keep the system working WordPress advises to use a minimum of 2 seconds. Because it cannot always get a response when set to 1 second.
When is this triggered?
Default timeout is 5 seconds for all requests. It increases for file downloads like WordPress updates and plugin downloads. But never decreased from default.
Timeout is useful for stopping unresponsive requests earlier as possible.
Solution
Set WP_HTTP request timeout to 2 seconds. HTTP Requests Manager plugin applies it in “Smart block” mode.
This optimization will not be applied for WP_HTTP requests used for downloading files.
Quantifiable Improvement: WP_HTTP request will complete 2.5 times faster when the network or remote server is busy. WordPress will get a failure response in 2 seconds instead of 5.
FAQ
How to make sure that important requests will not be blocked?
HTTP Requests Manager plugin blocks requests when they slow down your website. Plugin tested thoroughly and designed to make sure that code WordPress functionality is fully functional.
Additionally, the plugin does not limit by time or request count requests performed inside cron jobs. Important and slow requests should be performed in cron jobs or in small batches. Cron jobs are designed for such slow tasks and other plugin developers know and use it for this purpose.
If you want to make sure that important requests will never be limited then you can add it as a custom rule to always allow requests to certain domains or plugins. You can determine domain or plugin by analyzing recorded logs inside “Tools” → “HTTP Requests Plugin” page.
Which WordPress features use WP_HTTP requests most?
These are most used WordPress features that use WP_HTTP requests:
- Cron job – WP_HTTP is used to initiate cron jobs as a separate PHP process. It is initiated regularly to handle periodic or one time processes that usually take a long time to complete.
- Pingback – This is an old WordPress feature that is not used any more because of spam and security reasons. It is enabled by default and should be the first thing to disable on all websites. WordPress sends ping to every link every time a blog post is saved.
- Enclosure check – used to determine filetype of linked content inside blog posts. Enclosure checks are performed every time a blog post is saved.
- Update check – performed regularly to make sure that WordPress, theme and plugins are up to date.
Why are most cron jobs not visible in “Smart Block”?
There are too many cron jobs initialized in WordPress via WP_HTTP. In order to keep WP_HTTP log clean, “Smart block” mode logs cron jobs only on slow pages. This will not affect the cron functionality of WordPress because the next cron job will start in a couple seconds by a faster page.
To view all cron jobs started via WP_HTTP select “Only log HTTP requests (+ cron requests)” operation mode in HTTP Requests Manager plugin settings.
Report will be littered by too many requests when you log all cron job calls. Above screenshot shows that 95 cron jobs were recorded in 12 hours. In that time frame there were recorded only 5 WP_HTTP calls that were important.
Reporting all cron job calls will leave very little space to store and display important requests.
For this reason “Smart block” will not record all cron job calls. It records only cron jobs when they were blocked by total page time (3 seconds) or total request count (3 requests / page) limit.
How is cron job related to WP_HTTP?
Cron job in WordPress interacts with WP_HTTP in two ways:
- Any page can initiate (start) cron job using a non-blocking WP_HTTP request.
- WP_HTTP requests can be used inside cron jobs.
Pings, enclosure checks, update checks and other mass WP_HTTP requests usually start inside cron jobs.
What is the difference between blocking and non-blocking WP_HTTP requests?
Here are main differences between blocking and non-blocking requests.
| Non-blocking WP_HTTP request: | Blocking WP_HTTP request: |
|---|---|
| One way communication. | Two way communication. |
| Page sends requests and does not wait for response. | Page sends a request and waits until it gets a response. Page will not perform any other operation while it is waiting for response. |
| Page generation will be fast. | Page generation will be slow. |
Should I worry about WP_HTTP requests when WordPress is hosted on a super fast dedicated web server?
Yes, because the speed of WP_HTTP does not depend on your hosting. It depends on network speed and on the speed of the remote server.
For example, let’s say that a web server generates a page in 2 seconds. Every WP_HTTP request takes 1 second. So a page with 10 requests will be generated in 2+10= 12 seconds.
Web server only controls page generation time which is 2 seconds. Let’s assume that your web server can speed it up to 1 second with a faster web server. But your server cannot control the remote server and network connection to the remote server. So when you speed up your server total page time will be 1+11=11 second.
Even if your super fast dedicated web server can speed up page generation time to 0.1 second, total page time will be 0.1+10=10.1 second. Which is only 1.18x faster than regular WordPress hosting.
Big optimization for pages with WP_HTTP requests will be using “Smart block” mode in HTTP Requests Manager plugin. It will speed up to 4x for both slow and fast WordPress web servers.
Conclusion
Optimizing WP_HTTP calls is a crucial strategy for ensuring a smooth user experience and a strong SEO presence. HTTP Requests Manager plugin effectively addresses this issue by intelligently managing external requests, resulting in faster website loading times.
I explained how the plugin optimizes WP_HTTP requests in “Smart block” mode with related screenshots.
Improvement can vary depending on your WordPress and plugin usage.
Quantifiable improvement can be viewed in the first summary card of your report.
In addition to automatic website optimization plugin can be used to debug API calls. Debugging will help to fix WP_HTTP request errors or find and block useless requests for further optimization.
Give your website the speed boost it deserves! Try the HTTP Requests Manager plugin today and experience the difference for yourself.