Most performance advice you’ll find is either overly generic or hyper-specific to someone else’s stack. And yet diagnosing the actual reason your WordPress site feels slow doesn’t have to take hours or even a dev team.

In fact, once you understand how WordPress interacts with your server, your database, your plugins, and the browser, spotting bottlenecks becomes almost predictable.

I’m going to walk you through exactly how I approach diagnosing performance issues on a WordPress site. It’s fast, it’s methodical, and it tells me 90% of what I need to know in under 15 minutes.

Note: these steps are not in context. Meaning, I’m just showing you the 5 steps I take in general, not the steps I take given a specific performance issue.

Step 1: Get a Real-World Load Profile

I never start with lab tests like PageSpeed Insights. They’re useful, but they don’t reflect how real users experience your site under actual network conditions.

Instead, I run a fresh test on WebPageTest and SpeedVitals using

• A mobile device profile
• Throttled 3G or 4G speeds
• First view only (not cached)

The not cached part is super important because caching doesn’t solve performance problems. It just hides it really well. And, of course, I also look at the data inside Scanfully.

I choose a couple of pages that reflect real traffic, and those are typically the homepage or a high-traffic landing page or a product page.

I’m looking for four things:

• Time to First Byte (TTFB): Server-side responsiveness
• Largest Contentful Paint (LCP): How quickly your main content appears
• Cumulative Layout Shift (CLS): How stable your layout is
• Interaction to Next Paint (INP): How fast the site responds to user input

This gives me a baseline and also tells me where to dig next.

Step 2: Check Server and Stack Health

If TTFB is over 500 ms, I dig into the server setup. The TTFB basically tells me how long it takes for the server to process the request to render a given URL. Again, it’s super important to test this uncached.

What I’m looking for then is understanding the server’s stack. I want to know if the server is using a modern PHP version (8.2 or higher). Is object caching enabled (via Redis or Memcached)? Is the database sluggish or bloated with autoloaded options? Are we using indexes and modern storage engines in the database?

I look at whether the host supports persistent object caching. If it doesn’t, I know it’s very likely performance is going to suffer.

But of course, I also look inside of WordPress. I scan for bloated plugins that load globally across every page, but also do a deep dive into what kind of plugins are being used.

Tools I use here:

• Query Monitor
• Code Profiler Pro
• AAA Option Optimizer
• MySQL query logs if I have server access

Step 3: Frontend Bloat

Once I’ve ruled out or confirmed backend issues, I turn to the frontend.

I use Chrome DevTools and filter the Network tab to see:

• How many JS and CSS files the page loads
• Which third-party domains are involved (fonts, analytics, live chat)
• Whether any assets block rendering

That tab gets a couple of refreshes just so I can watch the waterfall of assets loading a few times. That alone can already give you a good visual representation of what’s happening on a page.

Not clicking on the document itself is a crime, btw. You’ll learn so much from clicking on that and then inspecting the headers.

Then I jump to the Performance tab, record a fresh session, and look for:

• Long JavaScript tasks
• Paint timing gaps
• Layout shifts

If I see 10+ font requests, unminified scripts, or large unused libraries (hello jQuery UI), I know we’re leaving speed on the table.

Step 4: Verify Caching

Remember how I said we need to test raw performance and not caching? Well, that is true, but that doesn’t mean we should not have any caching. We should. We should cache everything. All the time. Aggressively and smart.

Even if the backend and frontend look reasonable, poor caching or lack of a CDN can sink perceived speed.

I check:

• Whether full-page caching is working
• If headers like Cache-Control, Vary, and ETag are correctly set
• Whether image assets and static files are served via a CDN (Cloudflare, BunnyCDN, etc.)

Tools that help:

• Chrome DevTools
• curl or httpie to inspect headers
• WebPageTest’s repeat view test
• CDN logs, if available

This also tells me whether logged-in users, like WooCommerce customers, get a degraded experience compared to anonymous users.

Step 5: Prioritize

With all this info, I don’t just dump a list of 37 recommendations.

I stack the issues by impact and effort. If I can get a 3X improvement just by disabling a bloated plugin or switching caching layers, that comes first. Minifying CSS doesn’t move the needle nearly as much as eliminating slow database queries.

When I send a client a speed report, I group action steps into:

• Immediate gains (things you can fix today)
• Structural fixes (stack changes, caching setup, plugin audits)
• Monitoring going forward (Scanfully, custom alerts)

And if I find a plugin that’s responsible for 80% of the load, I’m going to say so directly, even if it’s popular. WPML is a perfect example of this.

There are three things I will always do:

1. Favor Edge Caching over just local Full-Page caching with NitroPack and Cloudflare APO being my favorites.
2. Install Perfmatters and use their Script Manager heavily.
3. If database usage is heavy, introduce Object Cache Pro (alongside Redis).

And very, very often I will want to move away from any page builders used to a Full Site Editing theme, if possible. There are exceptions when it comes to page builders, but it’s also criminally easy to create a slow site with the wrong settings, usage, and extensions.

You don’t need a full DevOps pipeline to spot why a WordPress site is slow. You need a clear process, a few good tools, and the willingness to dig deeper than the surface.

If you would like to understand everything about WordPress performance, every single layer well explained, you’ll find it inside my Make WordPress Fast course.

This approach works whether you’re troubleshooting your site, auditing a client project, or just building something you want to run fast. And once you’ve done it a few times, it really does only take 15 minutes.

Enjoyed this content? Check out what I’m building with The Guild to get more content like this.