This morning, I received a support email from a theme customer whose hosting company complained of high CPU load.

We determined it wasn’t the theme causing the CPU load (many use this particular theme with no CPU load complaints), however, I thought it would be worth writing a post to cover what high CPU load actually means, and how to correct it.

Overly simplified terminology

Computers are complicated beasts, but the basics of CPU load and memory usage will be explained below.


The CPU stands for central processing unit. On every computer (like a web server which every website is hosted on), the CPU handles all the basic processing of everything.

The lower the CPU usage, the better. When CPU usage gets too high on your computer, you’ll probably hear your fans kick into overdrive to cool it down. When it gets too hot in spite of cooling, the CPU will limit its own performance in an effort to cool down. If that doesn’t help, the computer will shut itself down in an effort to prevent damage to the CPU.

When a web server shuts down, all the websites hosted on it go down with it. So as you might imagine, web hosts can be pretty stingy about CPU load. Especially on a shared web server, where one CPU load-heavy website can potentially bring down websites hosted on other people’s accounts.


Different, but one that can cause similar adverse affects if overutilized, is memory usage. This is referring to the RAM (random access memory) utilization on the server. If too much memory is hogged by a problematic plugin, that’s less memory that can be used for basic server operations, which results in slowness.

Why you need to keep them under control

Most shared hosts will include clauses in their terms of service that high CPU load or memory usage can be grounds for account suspension. Many hosts won’t even give you a warning. They’ll just do this automatically to protect other customers on the same server.

It might seem harsh, but put yourself in the shoes of a well-behaving website. Would it be fair to have it shut down due to the actions of another problem website on the server?

No matter your hosting situation, it’s important to keep memory usage and CPU load under control.

Are you using a caching solution?

Something that every WordPress website should have in place, no matter how low the traffic.

Pretty much every managed WordPress host has its own built-in caching solution, so if you use one of those, no further action is necessary here.

If you’re on a cheap shared host, WP Super Cache is a good free choice. While I don’t personally use it, I’ve heard nothing but good things about WP Rocket, which is a paid solution.

Have you run a P3 scan?

GoDaddy created a plugin called P3, which stands for Plugin Performance Profiler. If there’s a poorly configured plugin on your site, P3 will find it.

If a problem plugin has been found, you can do one of three things:

  1. Try to fix the plugin to be more performant. This is the “take the most time” and “probably a lost cause” option.
  2. Seek an alternative plugin. This is the “might help, but might also suffer from the same problem” option.
  3. Deactivate the plugin altogether. This is the “probably for the best” solution. Can the function of the plugin be offloaded to a third-party service?

It could be that the type of plugin you’re using is just an inherent CPU hog.

Are you using inherently resource intensive plugins?

WP Engine maintains a list of disallowed plugins that are not allowed on the platform at all. Some are because they duplicate functionality, but others are because they’re just terrible. See under the “Server & MySQL Thrashing Plugins” heading.

  • Related Posts Plugins: Computing related posts algorithms are resource intensive, and should not be performed on a basic shared server. Look at Jetpack Related Posts to offload that to a third-party infrastructure.
  • Broken Link Checking Plugins: There’s absolutely no reason to ever use this plugin on a live site. Try it locally, or use a desktop app like Xenu’s Link Sleuth
  • Post View Counting Plugins: This requires writing to the database on each page load. And frankly, nobody cares how many post views you have. Display a share count from Facebook or something if you need “social proof.”

If you use any of the above, stop using them ASAP. If you really need the functionality, explore ways to off-load those resources to a trusted, third-party infrastructure. Offloading related posts computations to via Jetpack is a good example of that.

Are you under attack?

You might be thinking, “who would want to target me? I just run a small, uncontroversial website.”

The answer is: it doesn’t matter.

There are countless idiots who think it’s fun to take down honest people’s websites. I honestly can’t fathom the motivation behind it, so I don’t want to speculate too deeply as to why they do it, but it happens.

One of the most common is an XML-RPC attack. Unless you use some sort of desktop publishing app that requires XML-RPC enabled, there’s no reason to keep it enabled. Use the Disable XML-RPC plugin.

If that doesn’t help, all hope is not lost. A free CloudFlare plan can help block automated, malicious traffic.

Do you get a lot of traffic?

“A lot” is a very relative term, I know. But it’s important to put these sorts of stats in perspective.

For example, 500 visitors per day may not seem like much, but you can’t assume that all 500 visitors were evenly spread out throughout a 24-hour period. You have peak hours when the bulk of your visitors land on your site.

If those 500 visitors landed on your website at the exact same minute (an unlikely scenario, but consider it for example’s sake), your web server would likely buckle under pressure with that amount of concurrent users.

And if you were just look at daily stats, you wouldn’t have a clue as to why. It’s important to drill down to more specific measurements of time to gauge your server’s ability to handle traffic.

Is your host shaking you down?

Cheapo, sketchy shared hosts may be exaggerating or completely fabricating your CPU load woes as a ruse to get you to upgrade to a more expensive plan.

It’s difficult to prove, so don’t go around accusing your hosts of CPU load shakedowns. But if you have a gut feeling your host is pulling your leg, it may be worth exploring more reputable options.

Do you genuinely need to upgrade?

No matter how efficient the plugins you run are, no matter how aggressive your caching layer is, no matter how airtight your firewall is, some websites just simply outgrow their hosting accounts.

If the answers to all of the above questions were no, you may genuinely need a more accommodating hosting plan.

Previous Article
Realizing not every theme needs a layout editor
Next Article
Interviewing Sami Keijonen of Foxland