Szkoła Numerologii: a slow WordPress site at 100% CPU. After the rebuild, 10% at peak.

Slow WordPress site: where it comes from and how to fix it

A guide for owners of WordPress websites and online stores who can see that a slow WordPress site is eating into their sales, while their hosting provider only suggests a more expensive plan. We explain how to tell a server problem from an architecture problem, in what order to look for the causes, and when a rebuild pays off more than patching.

A slow WordPress site is usually an architecture problem, not a hosting problem

The first reflex when a site is slow is to buy a more powerful server. Sometimes it helps for a few weeks, and then the load goes back to the max. The reason is simple: if the site does a lot of unnecessary work on every visit, a bigger server will simply do more of the same unnecessary work.

In the Numerology School case described above, the server sat at practically 100% CPU all the time, and during traffic peaks the site took about a minute to respond. The cause wasn't a lack of resources, but 16 plugins adding queries and processes, plus a misconfigured cache. After the fix, the same Google traffic resulted in about 10% CPU at peak and close to 0% at idle.

A few signs that you’re looking at an architecture problem:

• the site slows down or crashes exactly at peak traffic, for example after a newsletter goes out;
• you pay for ever-larger hosting, and the load still sits at the max;
• logged-in users or the cart sometimes show incorrect or outdated data;
• traffic from Google is high, but sales are clearly lower than they should be.

Too many WordPress plugins: the most common culprit

Plugins are WordPress's biggest strength and, at the same time, the main source of slowdowns. Many of those installed “just for now” stay for years. Some add database queries on every page view, some run background tasks, and some load scripts and styles on pages that don't need them at all.

The problem rarely lies in the number of plugins as such. What matters is what each of them does on every request. That's why we start the review by asking whether a given plugin actually supports sales or customer service. If not, we disable it and measure the difference. At the Numerology School, we disabled 16 plugins after such a review.

Disabling plugins on a live store requires caution. It’s safer to test changes on a copy of the site, check the cart, payments, accounts, and forms, and only then move them to production. Before every change, you need an up-to-date backup of the files and the database.

Booking, calendar, and form plugins are a category of their own. They're heavy, deeply intertwined with the store, and often generate the most errors. In her video review, the client explicitly named the booking calendar as the most difficult part of the old site.

Caching in WooCommerce: a guest and a logged-in user are two different pages

Caching is the most effective way to speed up WordPress, but when misconfigured it can break a store. A page for an anonymous visitor can be stored in full and served from memory. A page for a logged-in customer contains their cart, orders, and account data, so it must be generated individually for them.

If the cache doesn’t distinguish between them, a logged-in user gets a version prepared for someone else. That’s what happened in the implementation described: the account and store showed someone else’s or outdated data. The fix was to separate the cache for guests from the logged-in session. This was the key fix that started the performance improvement and got the store working correctly.

WordPress server at 100% CPU: the diagnostic order

Under high load, it's easy to start changing everything at once and then not know what helped. It's better to stick to a fixed order and check the load in the hosting panel after each step:

• Baseline measurement. CPU load at peak and at idle, and page response time.
• Plugin review. Disable those that don't serve the business, and check which of the remaining ones are the heaviest.
• Cache configuration. Separately for guests and for logged-in users, excluding the cart and account.
• Database and queries. Offload the heaviest queries that run on every visit.
• Views and template. Limiting what loads on a single screen.

Only when these steps aren't enough does it make sense to talk about a bigger server. If the cause was plugins and caching, as in the case described, a bigger server turns out to be unnecessary.

Speed up your WordPress site or build a new one?

It depends on the current state. Sometimes stabilizing the existing site is enough; sometimes the old build is so overloaded that every fix breaks something else. A simple comparison helps:

At Szkoła Numerologii, we did both phases. First we stabilized the old site so it kept generating revenue. That gave us time to calmly build the new one: leaner views, a clean path to purchase, numerology calculators with product suggestions, and an automated appointment calendar. During the migration, only the store section was unavailable, for about an hour, while the rest of the site ran on cache.

This order has one big advantage: the rebuild doesn't happen under pressure. Once the old site responds and sells again, the new one can be designed, tested, and migrated calmly at a chosen moment, outside peak traffic. The owner doesn't have to do anything on their side in the meantime.

WordPress optimization isn't just a test score

Speed test scores are useful, but they aren't the goal. What matters is whether the site responds when the most purchase-ready visitors arrive. A slow WordPress site on a quiet morning is an inconvenience. The same site at peak traffic after a campaign means lost orders and wasted marketing budget.

That’s why, when optimizing, we look at three things at once: server load at peak, page response time, and the path from a Google visit to a purchase. A site that loads in under a second but leads the user through a wall of options still loses customers. In the case described, the layout change was just as important as the server fix.

If you'd like to check first what's slowing down your site, download website audit or go straight for the package Speed ​​Boost. We describe ongoing performance and update maintenance in our service website maintenance and development.