DEV Community

MD Pabel
MD Pabel

Posted on • Originally published at mdpabel.com on

Case Study: How We Debugged and Fixed High CPU Usage on a Low-Traffic WordPress Site

#backend #performance #php #wordpress

The Scenario

Recently, we investigated a performance issue on a client’s WordPress website. The symptoms were classic but confusing: the hosting provider was flagging the site for excessive CPU usage, yet the site itself was relatively simple. It wasn’t an e-commerce giant, and it didn’t have massive traffic spikes.

On paper, the server specs were more than enough to handle the visitor load. So, where were the resources going?

This case study breaks down exactly how we diagnosed the issue, the math we used to verify the cause, and the specific plugin settings that were silently killing server performance.

Phase 1: The Diagnosis (The “Smoking Gun”)

The first step in any performance audit is to look at the raw access logs or analytics. We immediately noticed a massive discrepancy between actual human visitors and server requests.

  • Homepage Views: ~6,800

  • admin-ajax.php Hits: ~21,000

The Red Flag: admin-ajax.php handles dynamic requests in WordPress. In a healthy environment, it shouldn’t be hit 3x more often than your most popular page unless you have a very specific application (like a complex logged-in dashboard).

The “Back of the Napkin” Math

Before opening a single code file, we did some quick math to see if the numbers told a story. We hypothesized that something on the homepage was firing multiple times per visit.

  • Total Homepage Visits: 6,800

  • Suspicious Requests per Visit: 3 (Hypothesis)

  • The Calculation: 6,800 × 3 = 20,400 hits

The result ( 20,400 ) was almost an exact match for the 21,045 hits reported in the logs. This confirmed that the issue wasn’t a bot attack or random traffic—it was a feature built into the site firing exactly 3 times for every single visitor.

Phase 2: Finding the Culprit (How to Debug)

To find out what was triggering these requests, we didn’t need expensive server monitoring tools. We just used the browser’s built-in Developer Tools.

Here is the exact workflow we used:

  1. Open Developer Tools: We opened the website in Incognito mode, right-clicked, and selected Inspect (or pressed F12).

  2. Monitor the Network: We switched to the Network tab.

  3. Filter the Noise: We typed admin-ajax in the filter box to hide images, CSS, and scripts.

  4. Analyze the Waterfall: We refreshed the page.

The “Aha!” Moment: Immediately, we saw multiple requests firing to admin-ajax.php. By clicking on one of these requests and looking at the “Payload” (or Params) tab, the specific culprit revealed itself.

The action parameter read: hustle_module_viewed.

This told us exactly what was happening: The popup plugin (“Hustle”) was firing a request to the database every single time a page loaded to record that a popup might have been viewed.

We also found a secondary culprit: a pixel tracking plugin firing an action called pys_get_pbid (fetching Pinterest data) via AJAX, adding seconds to the load time.

Phase 3: The Solution

Many site owners panic and delete plugins when this happens. However, usually, you just need to configure them correctly. We solved the issue without removing the functionality the client needed.

1. Disabling “View” Tracking

The popup plugin was tracking views (analytics) rather than just conversions (clicks). Writing to the database 21,000 times a month just to say “a user saw this popup” is a massive waste of resources.

  • The Fix: We located the specific module in the plugin settings, found the hidden gear icon next to the popup name, and selected “Disable Tracking.”

  • The Result: The hustle_module_viewed request vanished instantly.

2. Cleaning Up “Viewer Privacy”

We also noticed the plugin was logging IP addresses for every visitor.

  • The Fix: We set “IP Tracking” to Disable in the privacy settings and cleared the existing IP logs. This reduced database bloat and removed another write process.

3. Optimizing the Pixel Plugin

For the secondary issue, the Pinterest pixel was firing AJAX calls for a feature the client wasn’t even using aggressively.

  • The Fix: We disabled the specific ID for that platform and enabled the “Use REST API” option where available, which is generally lighter than admin-ajax calls.

The Result

After these simple configuration changes:

  1. CPU Usage plummeted back to normal levels.

  2. admin-ajax.php hits dropped by over 90%.

  3. Page load speed improved because the browser wasn’t waiting for background processes to finish.

Key Takeaways for WordPress Admins

If your host complains about high CPU usage, don’t just upgrade your plan.

  1. Check your Analytics: Look for admin-ajax.php or wp-cron.php in your “Top Pages” list.

  2. Do the Math: If the hit count is a multiple of your visitors, look for a plugin firing on every page load.

  3. Use the Network Tab: It is your best friend. Look for the action parameter in the payload to identify the specific plugin.

Do you have a slow WordPress site or mysterious CPU spikes? Analyzing your network requests is often the fastest way to find the hidden bottleneck.

Top comments (0)