WordPress Performance Audit: What to Check Before You Touch a Plugin
Most people's first instinct when a WordPress site feels slow is to start deactivating plugins. It's understandable, but it usually sends you down the wrong path. A proper WordPress performance audit works in a specific order, and plugins are rarely where the real problem lives. Get the sequence right and you'll spend less time guessing, find the actual bottleneck faster, and avoid breaking something that was working fine.
On this page
Start With a Baseline Measurement
Before touching anything, you need a fixed starting point. Run the site through Google’s PageSpeed Insights and note the scores for both mobile and desktop. Write them down. Screenshots work well too.
The numbers themselves matter less than having something to compare against later. Without a baseline, you genuinely cannot tell whether a change helped, hurt, or did nothing at all. It’s the most skipped step, and it’s the one that costs the most time.
Run the test three times and average the results. A single PageSpeed run can vary by 10 or 15 points depending on server load at that moment. One bad reading will send you chasing a ghost.
Check Your Hosting Before Anything Else
Hosting is the floor everything else sits on. A slow server produces a slow site, full stop, and no amount of caching or image compression will fix that. Look at your Time to First Byte (TTFB). A reading above 600 milliseconds at the server level points directly at infrastructure, not your theme or your plugins.
Shared hosting plans are the classic example of this trap. You might have a perfectly lean WordPress install, but if you’re sharing a server with hundreds of other sites, your TTFB will drag regardless. A plugin audit won’t touch that number.
The fix here is often a hosting upgrade or a move to a provider with proper server-side caching. That’s a bigger conversation, but it belongs at the start of the audit, not the end.
Look at Your Theme’s Actual Output
Heavy page builders and bloated themes load a lot of CSS and JavaScript that your pages never actually use. Open Chrome DevTools, go to the Coverage tab, and load a page. You’ll often see 70 to 80 percent of the CSS marked as unused. That’s the theme loading styles for components you haven’t built.
This is worth knowing before you start blaming plugins, because a theme generating 400kb of render-blocking CSS is a much bigger problem than most plugins will ever be. If your theme doesn’t give you control over what it loads, that’s a structural issue to address separately. You can read more about what themes actually load under the hood in our post on Core Web Vitals fixes that hold up in practice.
Audit Images Before You Audit Code
Unoptimised images are responsible for more slowness than almost any other single factor, and they’re often the easiest to fix. Look for images served at full resolution that are displayed at thumbnail size, PNGs where a WebP would do the job, and images with no lazy-loading attribute.
A product or portfolio page that loads 20 uncompressed JPEGs will score poorly no matter how optimised everything else is. Sort this before you move on.
- Check that images have defined width and height attributes to prevent layout shift
- Confirm that WebP is being served where the browser supports it
- Make sure images below the fold are lazy-loaded
- Look for any images wider than 1400 pixels that don’t need to be
Now Look at Render-Blocking Resources
Once hosting, theme output, and images are accounted for, render-blocking scripts and stylesheets are the next honest place to look. These are files that pause the browser from drawing the page until they’ve fully downloaded and processed.
In PageSpeed Insights, the ‘Eliminate render-blocking resources’ diagnostic will list them. CSS loaded in the document head is the usual culprit, followed by JavaScript that hasn’t been deferred or moved to load after the page. Disabling Google Fonts is one specific, measurable fix here. Our post on what happens to load time when you drop Google Fonts goes into that in more detail.
Plugins Come Last, and Only Then Systematically
After all of the above, plugins. Not before. We’d argue WordPress is probably the single most important website platform ever built, powering well over 40 percent of the web, and a big part of that is how well plugins extend it. But that flexibility means it’s easy to accumulate 30 plugins when 12 would do the same job.
The right way to audit plugins for performance is not to deactivate them randomly. Use a plugin like Query Monitor to see which plugins are adding database queries, and how many. Use the Network tab in DevTools to see which scripts are being loaded on each page. Then you have evidence, not guesses.
A plugin that fires 40 database queries on every page load is worth investigating. A plugin that loads one small script is almost certainly not your problem. Check the technical SEO foundations while you’re in there too, because slow pages and crawl budget are connected. The technical audit checklist here covers what to confirm before assuming performance is a content issue.
The order of all this matters more than most guides admit. Get it right and the audit takes a few focused hours. Skip straight to plugins and you could spend days on something that was never the cause.
Related: Page Speed Fixes That Actually Move Core Web Vitals