Skip to content

Find and Fix Slow WordPress Pages containing API Calls (undetected for years)

Website speed is important for ecommerce websites. Every additional second to the page load can lead to lost customers. That is the main reason to always monitor and optimize your WordPress website for speed.

In this tutorial I will show how to detect and optimize slow WordPress pages containing hidden API calls.

I am working on a WordPress website powered with the s2Member plugin. Site sells classified website building software.

S2Member plugin allows using encrypted PayPal buttons via API calls that prevents changing order value.

Find and Fix Slow WordPress Pages with Hidden API Calls (undetected for years)

How to know if you have slow WordPress pages?

There are many ways to check WordPress website speed like using online testing tools or simple WordPress info plugin.

Some of them will work while others will not always detect slow pages caused by API calls.

Thanks to the HTTP Requests Manager plugin I know exactly which pages on a given WordPress website are slow. And here is exactly how I found it.

HTTP Requests Manager plugin built to monitor and optimize WP_HTTP requests. I use it on all of my blogs to speed up WordPress admin pages.

Plugin records WP_HTTP usage. You can detect slow pages and excess usage of remote API calls with it. Recorded logs can be analyzed directly on the plugin page.

One day while checking recorded logs I found excess use of paypal API requests.

HTTP Requests Manager plugin detects excess usage of API calls in WordPress

WordPress was sending 94% requests to the PayPal website to generate an encrypted button. It is too much compared to other requests.

View instructions for detecting slow pages containing API calls.

Also I do not know how long this performance issue is happening. Probably for a couple years now.

After discovering slow pages by accident I started to investigate why slow pages were not noticeable via other site speed checking tools. I performed a couple tests and shared my findings further down in this article.

For now let’s find related pages and identify the main reason why they are slow.

Clicking on api-3t.paypal.com API link in the report reveals more details about the request.

View slow API call (PayPal), related plugin (s2MEmber), related page (Pricing).

From the screenshot we learn 2 things:

  1. Request made on /pricing/ page.
  2. Request initiated by s2Member plugin.

Clicking on “Check point” tab shows that there are 2 PayPal requests were made on pricing page.

2 PayPal buttons on Pricing page with unique URL causing WordPress performance issues

When we check the actual /pricing/ page (on screenshot) you can see 2 purchase buttons.

You will also notice the cache buster URL variable at the top. This prevents the page from being cached.

To summarize our findings:

  • We detected 94% requests using WP_HTTP class to PayPal API.
  • Requests were made on the Pricing page.
  • Remote API call is used for generating encrypted PayPal buttons on remote servers.
  • 2 remote requests were made per page. This is due to having 2 “Purchase” buttons on /pricing/ page
  • Pricing page is not cached. Which explains why they account for 94% of all requests on WordPress website.

Our goal is to reduce usage of PayPal API calls.

Let’s identify our priorities and find a solution to slow pages.

Prioritize functionality of slow pages

What do we want from the payment page?

We want the payment page to be secure and fast.

Payment process starts on /pricing/ page. There users check the price for software products and make a decision which plan they want to purchase. Then users select the desired plan and start the payment process.

Let’s break down how to make a payment page secure and fast.

Make payment page secure

Use an encrypted PayPal button on the payment page to make transactions secure.

We are already using an encrypted PayPal button on the pricing page. And we want to continue using it. Using encryption grants that users pay a declared amount for our software product.

Why is an unencrypted PayPal button not safe to use?

Because users can alter the payment amount for a plain PayPal button.

I had a bad experience using an unencrypted PayPal button.

Here is my experience…

In the past I have seen that unencrypted PayPal buttons can be altered and wrong amounts like 1$ can be paid instead of 74$. Payment amount is not double checked by s2Member so cheaters can instantly download our product without problem.

Then after some time when we get notified that a sale is made on our website we will notice that amount is not right and cancel the subscription of that user.

But users can still install and use our software once downloaded.

To prevent such fraudulent downloads it is advised to use encrypted PayPal buttons.

Why is the encrypted PayPal button slow?

Encryption is done on PayPal website. And this is why our payment page takes up to 5 seconds to generate.

To create an encrypted PayPal button s2member sends WP_HTTP request to PayPal API and gets encrypted button code. This process is done for each PayPal button.

Every time the payment page is visited, the plugin sends 2 API requests to PayPal , waits until a response is received and then completes generation of the payment page. After that page is sent to the user browser.

This process is very slow. We need to make it faster.

Make payment page fast

Potential customers can quickly load the page to view prices and purchase software products.

Payment page on website loaded in two ways.

  • First way is linked directly without the cachebuster URL variable.
  • Second, s2member redirects to the payment page when the user clicks on protected content. In this case the payment page will contain a unique URL cache buster variable. This page will not be served via cache and will be slow every time when visited.

There are 2 says to solve problem and make page faster:

  1. Always cache payment pages regardless of cachebuster URL.
  2. Make payment page load without cachebuster URL. (we chose this solution)

Given website uses 2 different caching layers. Page cache by WordPress plugin and server side caching by Nginx.

It will be not practical to add custom rules for a payment page into these caching solutions. Because in the future when we change caching plugins or add another caching layer like CDN caching all customizations can be overwritten and forgotten.

Also it is not practical to solve the problem of one plugin with modifying usage of other plugins and solutions.

For this reason we decided to use a second solution and update all links to protected content or Pricing page.

Fix slow pages containing API calls

How to fix slow payment pages in s2member?

We found that the payment page is slow because visits to protected content are redirected by the s2member plugin to the payment page with cachebuster URL variable. Causing generating a new payment page every time and making 2 API calls to PayPal Servers.

Cachebuster variable is actually “Membership Options Page / Variables”. It has information about which protected content was redirected to the payment page. Then this variable can be used to show custom content on the payment page.

Unique Membership Options Page Variables (MOP vars) in s2MEmber plugin makes caching ineffective.

You can see how “Membership Options Page / Variables” also referred to as “MOP vars” are added to the Pricing page.

Website has protected posts, download files and forums. In general there are more than 1000 protected URLs that redirect to the pricing page.

We cannot alter those protected URLs because they are indexed and regularly crawled by bots over the years.

Since we are not showing custom content on the payment page that depends on redirected variables. We can disable sending “Membership Options Page / Variables”.

Disable MOP vars in s2Member plugin. Used for WordPress pricing page.

To remove s2Member MOP vars from membership payment page:

  1. Navigate to “s2Member” → “General Options” from the WordPress dashboard side menu.
  2. Open the “Membership Options Page” tab.
  3. At the bottom find option “Enable MOP Vars” and select “No”
  4. Save changes.

After removing MOP vars only a single URL will be used for the Pricing page. This will eliminate having 1000 different URLs for pricing.

The Pricing page with a single variation of URL will be served from cache every time.

Optimization by removing MOP vars will be sufficient for most websites using the s2member plugin.

Bonus: Extreme optimization using static PayPal button

To optimize further we can hard code generated PayPal button HTML code directly into the pricing page. This will make the paypal button completely static. There will not be any requests to the PayPal API.

PayPal button as static HTML (fast) vs. s2Member shortcode (slow because of external API calls)

Here is how the static and shortcode PayPal button looks like.

Static PayPal button needs to be tested for some time. Also we need regular (weekly or monthly) checks and make sure that it works.

Static PayPal buttons can be helpful when you have too many encrypted PayPal buttons on the same page. Because each button sends a separate WP_HTTP request to PayPal API which takes around 2 seconds. This means that a single pricing page with 5 buttons will be generated in 10 seconds which is not acceptable.

Measure WordPress performance after optimization

Here is result of PayPal button optimization. API usage performance is constantly measured with HTTP Requests Manager plugin.

After optimization there is no more PayPal API calls detected by HTTP Requests Manager plugin.

After using static HTML buttons for PayPal we have not detected any new requests to PayPal API.

Our Pricing page also got faster and served from cache as expected.

FAQ

What to do if page slowed down by useless API call?

Block inividual API calls when they are not useful and slows down your WordPress website. Use “Custome Rule” inside “Settings” tab to block by domain or plugin. View tutorial to block individual API calls.

Why are some slow pages not detected by online speed testing tools?

Online site speed testing tools check pages on your request. In other words, manually. You enter the page URL you want to test and the tool will show how fast the page loads.

You need to test almost all of your website pages regularly. When it is only one page out of thousand different variations pages on your website it will be very hard to find that slow page.

Here is a screenshot or Pricing page tested with Google PageSpeed Insights.

Slow API calls cannot be detected with PageSpeed Insights tool. Pricing page generated in 5 seconds reported as fast page with 1.2 second page load time.

Wow, the report shows a high score of 98, meaning a very fast page.

In reality the actual page generated in 5 seconds, cached and loaded from cache in 1.2 seconds.

When we look only at this test then we cannot see that there are thousands of variations for the pricing page (refer to MOP vars above) that are not all cached and load very slow using many API calls and server resources.

Online testing tools are best for testing client side speed like Core Web Vitals but they struggle testing and reporting server side page generation speed.

For testing page generation speed you need to use plugins inside WordPress or reporting software inside your web server.

How to detect slow pages with server logs?

Nginx web server has enhanced logging functionality. It can record page generation time inside a general server access log.

Using a single line reporting command you can scan logs and list the top 100 slowest pages.

Check this report for a given website using Nginx server.

Slow WordPress pages detected by using Nginx custom logging and one line log summarizing Linux command. See that slow Pricing pages generated in 5 seconds.

From this screenshot you will see that pricing pages are the slowest pages for a given website. Page generation time is 5 seconds.

Additionally there are many variations for the pricing page which cannot be cached. You can see that Nginx cache status is shown as “MISS”.

This report should urge site administrators for WordPress optimization. Particularly to optimize /pricing/ page.

How to detect slow pages with WordPress plugin?

HTTP Requests Manager plugin can detect slow pages containing API calls.

HTTP Requests Manager monitors website passively and reports slow pages containing API calls.

Follow these steps to find slow pages caused by API calls in WordPress:

  1. Install and activate “HTTP Request Manager” from “Plugins” -> “Add new plugin” page.
  2. Navigate to “Tools” -> “HTTP Requests Manager” page and check that it is working and records some WP_HTTP requests.
  3. Wait couple days while plugin collects more requests.
  4. Check again “HTTP Requests Manager” page and select “Group by request domain” from dropdouwn box.
  5. See if you have many requests to remote APIs. Click on domain to reveal more information like responsible plugin and Page generation time.
  6. Click on single request to view related page information.

From screenshot above we can see that 94% requests were made to PayPal API. Request initiated by s2Member plugin. Page time was more than 2 seconds for latest requests.

Plugin keeps record of last 1000 API calls made using WP_HTTP function.

This can help to determine excess API calls and slow pages. That is exactly how we found out that the pricing page on a given WordPress website was slow for a couple years.

Conclusion

WordPress performance is important for making websites fast and being able to handle as many as possible pageviews daily. Performance checking can be neglected or not performed regularly. Some slow page issues can stay undetected for years. To prevent your website becoming slow over time it is good to have some sort of performance monitoring software.

In our case, by using the HTTP Requests Manager plugin, that was installed a couple days ago, we discovered a slow page which was undetected for many years. Plugin actually detected the exact request “PayPal API”, responsible plugin “s2Member” and page “Pricing page” that was slow.

We easily understood the reason and found a simple solution to the problem. Fixed slow page by removing custom variable from page URL and used static HTML code for encrypted PayPal buttons.

After fixing the problem we eliminated any WP_HTTP requests to the PayPal API. Our Pricing page became as fast as the rest of the website.

View more WP_HTTP debugging case studies.

Monitoring our own websites helped us to add more WordPress optimizations related to WP_HTTP usage into plugins’ “Smart Block” mode.

You can also monitor your WordPress performance and detect slow API calls by using the HTTP Requests Manager plugin.

Try it especially if you think that you do not have any slow API calls in your WordPress website.

Leave a Reply

Your email address will not be published. Required fields are marked *