There’s a difference between optimizing a WordPress site and triaging one.
Optimization is what you do when a site is fine but you want it to be faster. You run GTmetrix. You read about Core Web Vitals. You install a caching plugin. You tweak. You measure. You tweak again. It’s a slow, methodical, low-pressure exercise.
Triage is what you do when a site that was working yesterday is suddenly crawling today, the client is panicking, and conversions are dropping by the hour. There’s no time for methodical. There’s no time for “let me run a 30-minute audit.” You need to identify the cause in fifteen minutes and have a plan in thirty.
Most performance content online is about optimization. This article is about triage. Twelve years and thousands of WordPress sites later, here’s the actual process I use when a site is on fire.
The wrong question to ask first
Most operators, when faced with a suddenly-slow WordPress site, immediately reach for the optimization tools. They run PageSpeed Insights. They check Core Web Vitals. They look at TTFB.
This is the wrong move under pressure. Those tools tell you what is slow. They don’t tell you why. And when a site is suddenly slow, the why is almost never about the technical details those tools surface. It’s about something that changed.
The right first question isn’t “what’s slow?” — it’s “what’s the site actually doing right now that it wasn’t doing yesterday?”
That question routes you down a much faster diagnostic path.
Step 1: How many plugins is the site running?
This is the first thing I look at. Always.
It sounds almost too simple, but in my experience this is the single most common root cause of WordPress slowness, full stop. Not bad code. Not bad hosting. Not bad theme choices. Plugin count.
I’ve seen sites running 60, 70, 90 plugins. Some clients don’t even know what most of them do. They were installed years ago by a previous developer, or experimentally tested and never deactivated, or required by a feature that’s no longer used. Each one adds load to every page request. Each one queries the database. Each one ships front-end assets. The cumulative weight is often the answer, and the client is rarely aware of it.
A serious WordPress site running well should have somewhere in the range of 10 to 25 active plugins. If you’re looking at a slow site with 40+ plugins, your problem statement is already half-written.
Open the Plugins page. Count active plugins. Pay attention to anything that looks redundant, abandoned, or unfamiliar. You’re not looking for a smoking gun yet — you’re getting your bearings.
Step 2: Read the error logs
The error logs tell you what the site is actually struggling with — in its own words.
I go straight to cPanel’s error logs (or whatever logging interface the host provides). Modern managed hosts often have their own log viewers — use whichever is available.
Beyond the server logs, check WordPress’s own debug log.
Server error logs capture what’s failing at the PHP and Apache/Nginx level. They’re useful, but they don’t always surface WordPress-specific issues — plugin notices, deprecated function calls, theme warnings, slow database queries — that quietly degrade performance without throwing visible errors.
For that, WordPress has its own debug log: debug.log. Most clients don’t have it enabled.
To enable it, edit wp-config.php and add (or update) these lines above the /* That's all, stop editing! */ line:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );The first line turns on WordPress debug mode. The second tells WordPress to log errors to a file. The third and fourth ensure errors don’t display publicly on the front end of the site — critical, because you don’t want debug output visible to visitors.
Save the file. WordPress will start writing to /wp-content/debug.log automatically.
Reload the slow site a few times to generate fresh activity, then read the log. This is often where the real story lives. A plugin throwing 200 PHP Notice entries per page load isn’t fatal — the site keeps working — but it’s silently dragging performance down on every request. Server logs won’t catch this. debug.log will.
After triage, turn debug mode off (set WP_DEBUG back to false). Leaving it on in production is fine briefly for diagnosis, but you don’t want it permanently enabled — it adds its own small overhead and the log file will grow.
What I’m looking for:
- Repeated errors from a specific plugin
- PHP fatal errors or warnings spiking in frequency
- Database connection errors
- Memory exhaustion warnings
- Cron job failures
The pattern matters more than any single line. If one plugin is throwing the same error 400 times in the last hour, you’ve found something. If memory limits are being hit on every other request, you’ve found something. If cron jobs are failing repeatedly, you’ve found something.
A site under stress will tell you exactly what’s wrong if you read what it’s saying. Most operators skip this step because it feels less satisfying than running a fancy tool. It’s the most useful step.
Step 3: Check resource usage on the hosting plan
This is the step most freelancers skip and almost every senior operator runs first.
cPanel’s Resource Usage tool (or its equivalent on managed hosts) shows you whether the site has hit its resource limits in the last 24 hours — CPU, memory, I/O, entry processes, database connections, the whole picture.
When a site is “suddenly slow,” there are really only three possibilities:
- Something on the site changed (new plugin, new code, new traffic pattern)
- Something on the hosting side changed (resource limits hit, server under load, neighbor issues on shared hosting)
- Something at the network or DNS level changed (less common, but happens)
Resource Usage tells you whether #2 is in play in about ten seconds. If the site has been hitting its CPU or memory ceiling repeatedly in the last 24 hours, your problem isn’t WordPress — your problem is that this hosting plan no longer fits this site. No amount of plugin optimization will fix that. You need to upgrade the plan or migrate to a different stack.
This is one of the most common diagnostic findings I see, and almost no one checks it first.
Step 4: Identify the obvious culprit
By this point — usually within 10 to 15 minutes — you have three data points: plugin count, error log patterns, resource usage trends. Combine them.
Common patterns I’ve seen repeatedly:
Conflicting caching plugins. I’ve lost count of how many slow sites turned out to have WP Rocket, LiteSpeed Cache, and NitroPack all installed and active simultaneously. These plugins are not designed to coexist. Each is trying to do the same job, and they conflict in ways that can make the site slower than running no caching at all. Same goes for image optimization plugins, security plugins, and SEO plugins. If a site has two of the same category active, that’s almost always the answer.
Cron job stampedes. A plugin (often a security plugin, backup plugin, or analytics plugin) is running an aggressive cron job that fires too frequently. Every page load triggers a cascade of WP-Cron events that should have been spread across hours. The site slows to a crawl during these stampedes. The fix is usually disabling WP-Cron and replacing it with a system cron, or tracking down which plugin is being overzealous.
A specific abandoned or broken plugin. Sometimes there’s just one plugin that’s incompatible with the current PHP version, or that’s making an external API call to a service that no longer responds, or that’s running an infinite loop on certain requests. The error log will name it.
Theme issues. Less common than plugin issues, but real. Particularly with bloated commercial themes or themes that were heavily customized years ago by a previous developer. If plugins check out clean, the theme is the next suspect.
A traffic spike the hosting plan can’t handle. The site was fine for months at 5,000 monthly visits and suddenly slow this week because a piece of content took off and traffic 10x’d. The site doesn’t have a problem — the plan has a problem. Migrate up.
Once you’ve identified the obvious culprit, you can move from triage to fix. But not before.
What I don’t do during triage
I don’t run PageSpeed Insights. I don’t run GTmetrix. I don’t check Core Web Vitals. I don’t install Query Monitor and start profiling database queries. I don’t audit the theme’s CSS bloat.
Those are optimization tools. They tell you which parts of a site are slow in absolute terms. But during triage, I’m not trying to make a working site faster — I’m trying to figure out what broke. Optimization tools don’t help with that, and reaching for them under pressure wastes the most valuable thing you have during an incident: time.
There’s a time and place for those tools. It’s not in the first thirty minutes of a slow-site incident.
Where AI fits in
This is where the process changes meaningfully for me from how it used to look.
When I’m triaging a site now, I copy error log excerpts directly into a Claude or ChatGPT window. The AI parses them in seconds, summarizes the patterns, points out which plugins or themes are mentioned most often, and suggests a priority order for what to check. What used to be a 10-minute exercise of squinting at raw log output and recognizing patterns by hand is now a 30-second conversation.
I also use AI to parse plugin lists. I’ll paste in a list of 60 active plugins and ask for an analysis: which ones are commonly known to be heavy, which ones often conflict, which ones might be redundant. The AI can’t replace operator judgment — it doesn’t know your specific stack, your client, or the history of the site. But it accelerates the parts of the work that are pattern-recognition heavy, which most of triage is.
The honest result: client satisfaction is higher because the diagnosis happens faster. A problem that used to take 45 minutes to identify now takes 15. The client experiences this as competence. It is competence — just accelerated.
After enough repetitions, I packaged the whole method into a free plugin. Triage runs the nineteen checks I’d otherwise be running by hand — plugin count, autoload size, transient bloat, cron health, the works — then hands the findings to Claude and asks for a prioritised verdict. The diagnostic that used to take fifteen minutes runs in sixty seconds. Same pattern recognition, compounded. Bring your own Claude key; nothing routes through me.
This is the AskSaber thesis applied to my own work. AI doesn’t replace twelve years of pattern recognition. It compounds it. The operators who learn to wield both move at a speed that’s hard to match with experience alone.
The triage mindset
What separates triage from optimization isn’t the tools. It’s the mindset.
In triage, you’re not trying to make a site great. You’re trying to figure out what broke and stop the bleeding. Your goal is to identify the single most impactful issue, address it, and get the site back to working. Anything beyond that — performance tuning, Core Web Vitals, caching strategy — is a separate engagement that happens after the fire is out.
This is also why I don’t bill triage work the same way I bill optimization work. Triage is a focused diagnostic that runs in under an hour for an experienced operator. It’s part of every audit I do. If the underlying issue requires a separate engagement to fix properly — migrating hosting, rebuilding the plugin stack, replacing a custom theme — that’s a different conversation, scoped after triage is done.
The framing matters. If you treat every slow site like an optimization project, you’ll spend hours on the wrong work while the client’s site is still down. If you treat every slow site like an emergency room intake — identify the most acute issue, address it, then triage the next one — you’ll be much faster, much calmer, and much more useful.
The short version
When a WordPress site is suddenly slow, in order:
- Count active plugins. If it’s over 40, you’ve already half-diagnosed the problem.
- Read the error logs. They tell you what the site is struggling with.
- Check resource usage. If the plan is maxed out, the answer is the plan, not the code.
- Look for the obvious culprit: conflicting plugins, runaway cron jobs, abandoned dependencies, traffic spikes the plan can’t absorb.
- Use AI to compress steps 2–4 by an order of magnitude.
Don’t reach for optimization tools during triage. Don’t profile when you should be reading logs. Don’t tune what isn’t broken.
The fastest operators aren’t the ones with the deepest tools. They’re the ones who know which question to ask first. After twelve years and thousands of sites, mine is always the same one:
What is this site actually doing right now that it wasn’t doing yesterday?
The answer is almost never where you’d expect — but it’s usually in the first three places I named above.
— Saber