WordPress Performance Audit: How to Find What’s Slowing Down Your Site

If your website has ever felt slow, it’s likely that your approach to researching and fixing it looked something looks like this:

1. Run PageSpeed Insights.
2. See a red score.
3. Install a caching plugin.
4. Hope for the best.

Sometimes that works, but more often than not, the score barely moves because they’ve applied a generic fix to a problem they never actually diagnosed.

A performance audit changes that. It’s a way of working through your site methodically, using the right tools in the right order, to figure out exactly what’s causing the slowdown before you change anything. This tutorial walks through that process step by step using only free tools. By the end, you’ll have a clear picture of what’s wrong and what to fix first.

This is written for WordPress site owners who aren’t performance experts. You don’t need to touch any code or use the command line.

What You’ll Need

Spare 30 to 45 minutes of your time today and open up the following:

• A Google Search Console account with your site verified
• Google PageSpeed Insights (no account needed)
• A free GTmetrix account (unlocks all the details you need)
• The Query Monitor plugin (install on your WordPress site)

Step 1: Start in Google Search Console

Before you run a single speed test, open Google Search Console and navigate to Experience > Core Web Vitals in the left sidebar.

Most performance guides skip this step and jump straight to a speed test. That’s a mistake, and here’s why.

Every tool in this tutorial (except this one) shows you “lab data,” which is a simulated test run from a single location on a single device. Search Console is different. It shows you real performance data collected from actual visitors to your site over the past 28 days. Google calls this “field data”, and it’s the closest thing you’ll get to seeing your site through your readers’ eyes.

If Google is using any data to inform your search rankings, it’s this.

The report groups your pages into three categories: Good, Needs Improvement, and Poor. It also tells you which specific metric is causing the problem for each group. That last part is important. A site with LCP problems needs a different fix from a site with CLS problems. Knowing which one you’re dealing with before you start saves a lot of wasted effort.

A couple of things to know before moving on. If your site has low traffic or was launched recently, you may not have enough visitor data for the report to show results. If that’s the case, skip ahead to Step 2. Search Console also won’t explain why a metric is failing, only that it is. The steps that follow take care of the diagnosis.

Step 2: Drill Into PageSpeed Insights

Take the worst-performing page type from Search Console and run it through PageSpeed Insights. If Search Console didn’t have data for your site, start with your most important page. For most sites that’s the homepage. For a content-heavy blog, it’s worth testing one of your most-visited posts too, since those pages often have different performance profiles.

When the results load, here’s what to focus on.

Look at the mobile score first, not desktop. Google uses your mobile performance for ranking purposes. It’s common for a site to score 80 on desktop and 34 on mobile. The mobile number is what matters.

Check for TTFB-related issues in the Diagnostics section

This refers to your Time to First Byte, which measures how long your server takes to start responding when someone visits a page. Think of it as the time between clicking a link and the page beginning to appear.

If PageSpeed flags this and your TTFB is above 600ms, your hosting is the root cause. Importantly, if this diagnostic is absent, that’s actually good news. It means your hosting is probably not the problem and you can focus elsewhere.

Look at the Insights section for render-blocking requests

This is one of the most common and most impactful issues on WordPress sites. Render-blocking means certain CSS or JavaScript files are loading early and forcing the browser to pause before it can display anything on screen.

If PageSpeed flags this with a high estimated savings figure (anything over 1,000ms is significant), it’s almost certainly your biggest priority. Note that this is separate from Total Blocking Time: a site can have perfectly fine TBT and still be badly affected by render-blocking resources.

Check which element is your Largest Contentful Paint

LCP measures how long it takes for the biggest visible item on your page to load. PageSpeed tells you exactly which element that is. Most of the time it’s the hero image at the top of the page

If it’s flagged, check whether the image has been compressed, whether it’s being served in WebP format (a smaller, more efficient file type), and whether it has lazy loading applied to it. That last point trips up a lot of people. Lazy loading tells the browser to delay loading an image until the user scrolls near it, which is useful for images further down the page but actively harmful for your hero image. Your LCP image should always load immediately.

Check Total Blocking Time

TBT measures how long your page is technically loaded but not yet responding to clicks or taps. High TBT is usually caused by heavy JavaScript execution. If TBT is green, that’s one less thing to worry about, but it doesn’t mean JavaScript isn’t causing other problems elsewhere, so check the unused JavaScript diagnostic in the Diagnostics section too.

In general, make sure to scroll through the full Insights and Diagnostics sections. PageSpeed orders everything by estimated impact, so the items at the top with the largest savings figures are where to focus first.

Step 3: Cross-Check with GTmetrix

PageSpeed Insights tells you what is failing. GTmetrix helps you understand the loading sequence, which makes it much easier to see why.

Log into GTmetrix, run the same URL, and once the report loads, click the Waterfall tab.

The waterfall chart looks complicated at first, but the idea is simple. It shows every file your page loads as a horizontal bar, positioned on a timeline. The further right the bar extends, the longer that file took to load.

A few things to look for specifically:

1. A long gap at the very start before anything loads is referencing your server response time again. If there’s a noticeable pause before the first bar even begins, your hosting is likely the bottleneck.
2. Wide bars on image files typically mean large uncompressed images. If you see an image taking 2 or 3 seconds to load on its own, that’s almost certainly hurting your LCP score.
3. Early-loading CSS or JavaScript files that block everything else, which are called render-blocking resources. GTmetrix highlights them, and they’re worth addressing because they delay the point at which your page starts appearing on screen.
4. Third-party scripts near the end of the waterfall, like analytics tools, live chat widgets, and social media embeds often load late and slow down the point at which your page becomes interactive. If you spot a third-party script adding a significant delay, that’s useful to know before spending time optimising other things.

The Structure tab in GTmetrix gives you a recommendations list similar to PageSpeed Insights, but with slightly different analysis. If the same issue appears in both tools, treat it as a high-priority target.

Step 4: Check Your Server-Side Performance with Query Monitor

The first three steps are all about what happens in the browser. This step looks at what’s happening on your server before the browser receives anything at all.

Install Query Monitor from your website’s Plugins section (it’s free). Once it’s active, it adds a small menu to your admin toolbar. Load any page on your site while logged in as an administrator, then click the Query Monitor item in the toolbar to open the panel.

You don’t need to be a developer to find useful information here. The three panels worth checking are the following.

Database Queries

This lists every database query your site runs to build the current page, how long each one took, and which plugin or theme generated it. A typical well-optimised page runs somewhere between 20 and 50 queries. If you’re seeing 150 or more, or if individual queries are taking longer than 50ms, you have a backend performance problem. Query Monitor will usually point to a specific plugin as the source.

HTTP API Calls

This shows any requests your server is making to external services while building the page. Some plugins phone home to remote APIs on every single page load, which adds latency that no caching solution can eliminate. If you see unexpected external requests here, the plugin responsible is worth investigating.

Hooks and Actions

This is more technical, but if your pages are slow even though your hosting and images look fine, this panel can reveal plugins that are running unnecessarily heavy processes on every page load.

Even a quick look at the Queries panel alone is usually enough to spot whether a specific plugin is creating a disproportionate load.

Step 5: Build Your Priority List

At this point you have data from four different sources. The goal now is to turn that into a short, ordered list of actions rather than trying to fix everything simultaneously.

Work in this sequence:

Hosting first

If TTFB is flagged in PageSpeed Insights and you can see a long initial gap in the GTmetrix waterfall, fix the hosting before anything else. A performance-focused managed host like Servebolt or Kinsta will reduce your server response time significantly. Other optimisations build on top of a fast foundation, not the other way around.

Images second

If your LCP score is failing and your hero image is the culprit, that’s a focused, high-impact fix. Compress the image, convert it to WebP, make sure lazy loading is turned off for it specifically, and re-test. A well-optimised hero image can move your LCP score substantially on its own.

Code and caching third

If your server is fast and your images are sorted but you’re still scoring poorly, you’re most likely dealing with render-blocking scripts, unused CSS, or missing page caching.

An all-in-one performance plugin handles most of this: FastPixel covers caching, image optimisation, code minification, and CDN delivery in a single install. Before installing anything, check whether Query Monitor flagged a specific plugin as a problem. Removing one bloated plugin sometimes does more than any amount of caching configuration.

Third-party scripts last

Analytics, chat tools, and ad scripts are often outside your direct control, and the trade-offs involved (removing something useful to gain a small speed improvement) are harder to justify. Come back to these once the bigger issues are resolved.

One important habit: record your baseline scores before making any changes, and re-test after each individual fix rather than applying everything at once. That way you know exactly what worked, and you’re not left guessing when something unexpected happens.

What’s Next

Running this audit once is genuinely useful. Making it a regular habit is what keeps your site healthy over the long term.

WordPress sites tend to drift. Plugins pile up, images get uploaded without compression, and a setup that was clean twelve months ago can quietly degrade without anyone noticing. A quick version of this process every few months catches problems before they start affecting your traffic or your readers’ experience.

If the audit turned up issues you’re not sure how to fix, the WordPress speed guide explains the root causes behind each type of problem, and the speed optimisation tips article covers the specific tools and settings to address them.

What did your audit surface? If you’re looking at your results and not sure what they mean, drop a comment below and I’ll take a look.