WordPress Performance Audit Checklist: Find Exactly Why Your Site Loads Slowly

A slow WordPress site is not a mystery – it is a sequence of fixable problems that most developers never isolate because they skip the measurement step. This checklist walks through 10 stages of a systematic performance audit, from taking a baseline reading all the way to evaluating whether your hosting is the bottleneck. Work through each stage in order. Every step narrows the problem and gives you data to back up whatever fix you apply next.

---

Why Most Performance “Fixes” Do Not Work

The most common mistake in WordPress performance work is applying fixes before measuring. Someone installs a caching plugin, enables a CDN, and “optimizes” images – and then wonders why the site is still slow. The reason is that these changes targeted assumptions, not data.

A well-run performance audit follows measurement at every stage. You take a baseline reading, isolate one variable at a time, verify the impact, and move to the next stage. The checklist below does exactly that, in the order that surfaces root causes fastest.

The goal of a performance audit is not to enable every optimization option available. It is to identify the two or three changes that will produce 80% of the improvement.

---

Step 1: Measure Baseline Performance

Before touching anything, measure. A baseline reading gives you a reference point to compare against after every change. Without it, you have no way to know if your fixes actually helped, hurt, or did nothing.

Tools to Run in Parallel

Run all three of these on the same URL, ideally your homepage and the slowest page you know about (a category archive, a complex product page, a landing page with many plugins active):

• Google PageSpeed Insights – shows Core Web Vitals (LCP, CLS, INP) from real user data (CrUX) plus lab data from Lighthouse. The field data matters more than the lab score.
• GTmetrix – provides waterfall view, shows each asset load time, and reports TTFB separately from total load. The waterfall is the most useful view for identifying bottlenecks.
• WebPageTest – runs tests from multiple geographic locations, produces a detailed timeline view, and can run filmstrip comparisons side by side. Useful for verifying CDN coverage and spotting render-blocking assets.

Record these numbers before touching anything:

Metric	Your Baseline	Target
TTFB (Time to First Byte)	___	Under 200ms
LCP (Largest Contentful Paint)	___	Under 2.5s
Total Page Size	___	Under 1MB
Total Requests	___	Under 50
PageSpeed Score (Mobile)	___	Above 70

Run each test three times and use the median result. A single test run is unreliable because server load, DNS resolution time, and CDN cache state vary between runs.

---

Step 2: Check Server Response Time (TTFB)

TTFB – Time to First Byte – is the time from when a browser sends a request to when it receives the first byte of the response. It is the single most important number in the baseline because it measures everything that happens on the server before any asset loads: PHP execution, database queries, caching, and network latency to the server.

A TTFB above 600ms almost always indicates a server-side problem: slow PHP, uncached pages, slow database queries, or an undersized server. A TTFB below 200ms means the server is healthy and further improvements come from the front end.

What High TTFB Tells You

TTFB Range	Likely Cause	Next Step
Under 200ms	Server is healthy, page cache working	Move to Step 5 (assets)
200-600ms	Slow PHP, partial caching, or plugin overhead	Check Steps 3 and 4
600ms-1s	No page cache, slow database queries	Priority: Steps 3 and 7
Above 1s	Hosting bottleneck or severe DB problem	Steps 3, 7, and 10

Also check TTFB with a logged-in admin session versus a logged-out visitor. If TTFB is fast for visitors but slow for admins, your page cache is working correctly but admin pages bypass it. If TTFB is slow for everyone, your page cache is either misconfigured or not installed.

---

Step 3: Profile Slow Database Queries with Query Monitor

Install the Query Monitor plugin from the WordPress repository. It adds a persistent admin bar panel that breaks down every database query on the current page: which plugin triggered it, how long it took, and whether it was duplicated.

Load the slow page with Query Monitor active and open the panel. The tabs you care about most are:

• Queries – total count, cumulative time, and each query’s SQL with caller information
• Duplicate Queries – identical SQL run more than once on the same page (these are always bugs, not intentional design)
• Queries by Component – which plugin or theme is responsible for the most queries
• Slow Queries – any query above the configured threshold (default 0.05s)

A page running more than 50 database queries is flagging a problem. A well-optimised WordPress page runs 15-30 queries. Anything above 100 queries on a single page load means something is structurally wrong.

Using SAVEQUERIES for Deeper Analysis

For staging environments where you want to log queries without the admin bar, enable SAVEQUERIES in wp-config.php (our wp-config.php hidden settings guide covers this and 14 other useful constants). This stores every query, its execution time, and the call stack in $wpdb->queries. Add a shutdown hook that dumps them sorted by slowest first – this surfaces the worst offenders in one pass.

The companion article on finding and fixing slow database queries covers SAVEQUERIES, EXPLAIN analysis, and index strategies in full detail. If Step 3 surfaces a query-heavy plugin or slow individual queries, work through that guide before continuing this checklist.

---

Step 4: Profile Plugins for Load Impact

Plugins are the most common cause of WordPress performance problems. A single plugin that runs poorly written queries on every page load, loads unnecessary assets, or fires expensive hooks on every request can add hundreds of milliseconds to TTFB.

Manual Deactivation Testing

The most reliable way to isolate a problematic plugin is binary search deactivation: deactivate half your plugins, measure TTFB, and check whether it improved. If yes, the problem is in the deactivated group. Reactivate half of those, measure again, and repeat until you isolate the culprit.

WP-CLI makes this faster than doing it through the admin panel. The commands above let you deactivate all plugins at once, then reactivate them one by one while measuring TTFB between each reactivation. The moment TTFB spikes, you have found the culprit.

What to Do When You Find a Slow Plugin

1. Check if the plugin has a caching setting you haven’t enabled – many plugins cache by default but ship with it off
2. Check whether the plugin loads on every page or only when specifically needed – use its settings to restrict loading to relevant pages only
3. Check when the plugin was last updated – an abandoned plugin running on a modern PHP version may have compatibility overhead
4. Search the plugin’s support forum for performance complaints – if other users report the same problem, it is a known issue not an isolated finding
5. If none of the above resolves it, benchmark a replacement plugin that covers the same feature

Query Monitor’s “Queries by Component” view gives you the plugin-level breakdown without needing to deactivate anything. Use it as a fast triage tool before committing to manual deactivation testing.

---

Step 5: Audit Render-Blocking CSS and JavaScript

After TTFB, the next biggest impact on perceived load time comes from render-blocking assets. CSS and JavaScript files loaded in the document head block the browser from rendering anything visible until they finish downloading and parsing. On a typical WordPress install with 10-15 active plugins, this can add 500ms-2s of blocking time on mobile connections.

Identifying Render-Blocking Assets

The GTmetrix waterfall view shows which resources block rendering – look for a long empty space at the top of the waterfall before the first content paint. Google PageSpeed Insights also lists specific render-blocking resources under “Opportunities.”

The WP-CLI approach above uses the script and style enqueue system to list what is loaded on each page. Cross-reference this list against what you see in the browser’s network panel – any script loading in the head without defer or async attributes is blocking.

Fixes for Render-Blocking Assets

Asset Type	Problem	Fix
CSS in head	Blocks first paint	Inline critical CSS, defer non-critical
JS without defer	Blocks parsing and rendering	Add defer or async attribute, or move to footer
Google Fonts	Adds external DNS lookup + file request	Self-host fonts or use font-display: swap
jQuery loading early	Blocks all jQuery-dependent scripts	Move to footer if no inline scripts depend on it
Plugin CSS loaded on every page	Unnecessary load on unrelated pages	Conditionally enqueue based on page/post type

WordPress 6.3 added native support for specifying defer and async on scripts registered via wp_enqueue_script() using the $args parameter. For older installs, caching plugins like WP Rocket and LiteSpeed Cache offer asset optimization that adds defer attributes across all enqueued scripts automatically.

---

Step 6: Audit Image Optimization

Images are usually the largest contributor to total page size. Unoptimized images on a WordPress page can easily add 2-5MB per page load. The combination of correct format selection (WebP or AVIF), proper sizing, and lazy loading addresses most of this overhead without changing the visual output.

The Image Optimization Checklist

• Format – Are images served in WebP or AVIF? JPEG and PNG should only appear as fallbacks for browsers that do not support modern formats.
• Dimensions – Are images sized to match their display size? A 3000px wide image displayed in a 800px column is wasting bandwidth on every request.
• Compression – Have images been compressed? A losslessly compressed JPEG is rarely smaller than 85-quality lossy. Target under 100KB for most content images.
• Lazy loading – Is loading="lazy" on images below the fold? WordPress adds this automatically since 6.3, but older themes and plugins may override it.
• LCP image – Is the largest content element (usually the featured image or hero) explicitly excluded from lazy loading? Lazy loading the LCP image delays the LCP metric.

The WP-CLI commands above identify images missing the loading attribute and check whether WebP versions exist for uploaded images. WordPress generates WebP versions automatically when the server has the WebP library available – check wp eval 'echo gd_info()["WebP Support"];' to verify.

Bulk Regeneration After Format Changes

If you enable WebP support or change image sizes after the fact, existing uploads will not be automatically regenerated. Run wp media regenerate --yes to regenerate all image sizes. On large media libraries, run this during off-hours – it is CPU-intensive and can take an hour or more on shared hosting.

---

Step 7: Audit Caching Layers

WordPress has three distinct caching layers, and most performance guides only address one of them. A complete audit checks all three because a gap in any layer creates a bottleneck the others cannot compensate for.

Layer 1: Object Cache

WordPress’s built-in object cache is per-request only – it resets every page load. Without a persistent object cache backend (Redis or Memcached), every page load re-runs database queries that return the same data. Add Redis via the Redis Object Cache plugin and all wp_cache_get() calls persist across requests. The queries still run on the first hit, but subsequent requests return cached results instantly.

Layer 2: Page Cache

Page caching stores the complete HTML output of a page and serves it directly, bypassing PHP and the database entirely for cached pages. This is what brings TTFB from 800ms down to 50ms for anonymous visitors. WP Rocket, W3 Total Cache, LiteSpeed Cache, and most managed hosting platforms (Kinsta, WP Engine, Cloudways) all provide page caching. Verify it is working by checking response headers.

Layer 3: Browser Cache

Browser caching instructs the visitor’s browser to store static assets (CSS, JS, images, fonts) locally and reuse them on subsequent page loads instead of re-downloading. Without proper cache headers, every page load re-downloads every asset. With them, repeat visits load in a fraction of the time.

The commands above verify all three layers. Look for X-Cache: HIT or similar headers confirming the page cache is serving the response, Cache-Control headers on static assets showing appropriate max-age values, and the Redis Object Cache plugin’s stats page showing a high cache hit ratio (target above 80%).

If page cache headers are absent and TTFB is above 600ms, installing a page cache plugin is likely the single highest-impact change you can make. It costs nothing and typically reduces TTFB by 70-90% for anonymous visitors.

---

Step 8: Verify CDN Setup and Coverage

A CDN (Content Delivery Network) serves static assets from servers geographically close to the visitor, reducing the network latency component of asset load times. For sites with a global audience, a CDN is essential. For sites with a regional audience, it is still worthwhile for the HTTP/2 multiplexing benefits and the reduced load on the origin server.

What to Check in Your CDN Configuration

• Are static assets (CSS, JS, images, fonts) being served from the CDN domain rather than the origin?
• Is the CDN configured to cache pages as well as assets, or just assets?
• Are CDN cache headers set to appropriate max-age values (1 year for versioned assets, shorter for HTML)?
• Is Cloudflare or your CDN aggressively caching pages that should be dynamic (cart, checkout, account pages)?
• Are media uploads in /wp-content/uploads/ served from the CDN?

The verification commands check whether assets return CDN headers, confirm the CDN is not aggressively caching dynamic pages, and test load times from multiple geographic locations. A CDN working correctly will show CF-Cache-Status: HIT (Cloudflare) or similar headers on static assets, with low TTFBs from distant test locations.

---

Step 9: Clean Up the Database

Database bloat does not usually slow a site down dramatically on its own – the query optimizer handles larger tables reasonably well. But two specific database problems in WordPress cause real page load impact: autoloaded options bloat in wp_options, and table fragmentation from years of content editing.

The wp_options Autoload Problem

WordPress loads all rows from wp_options where autoload = 'yes' on every single page request, before rendering anything. Plugins that store large serialized arrays with autoload enabled force the server to deserialize megabytes of data on every page load. The target is to keep total autoloaded options under 800KB.

Run the audit query first – it shows you the biggest autoloaded options by size. Investigate the largest ones before touching them. Some are legitimate (site configuration, critical plugin settings). Others are caches that should never have autoload enabled (transients, large serialized caches from page builder plugins). Our wp_options autoload bloat guide walks through the full fix with before-and-after benchmarks.

Post Revisions, Orphaned Meta, and Table Fragmentation

Post revisions accumulate silently. A heavily edited post can generate hundreds of revision rows, each with its own wp_postmeta entries. Set define( 'WP_POST_REVISIONS', 5 ); in wp-config.php to cap future accumulation, then clean existing excess revisions with WP-CLI:

Use wp post delete $(wp post list --post_type=revision --format=ids) --force to delete all existing revisions after capping the limit. Run wp db optimize afterward to defragment the tables and reclaim space.

The full guide on database maintenance, OPTIMIZE TABLE, and cleanup covers this in depth with automation scripts for monthly maintenance.

---

Step 10: Evaluate Your Hosting

If TTFB remains above 600ms after addressing database queries, plugins, and caching, the bottleneck is the hosting infrastructure itself. PHP execution time, available memory, CPU allocation, and disk I/O speed all set a ceiling on what WordPress can achieve regardless of any optimization you apply at the code layer.

Signs Your Hosting Is the Bottleneck

• TTFB remains above 600ms after enabling page caching (cached responses should be under 100ms)
• PHP memory limit is at or near the configured maximum under normal traffic
• Database query times are within normal range but overall TTFB is still high
• CPU usage spikes during normal traffic (not traffic bursts)
• Slow performance is consistent across all pages regardless of their content complexity

What to Look For in Benchmark Results

Benchmark	Shared Hosting	Managed WP Hosting	VPS / Dedicated
PHP execution (simple request)	100-300ms	20-80ms	10-50ms
MySQL query (simple SELECT)	5-20ms	1-5ms	1-3ms
Memory available per PHP process	64-128MB	128-256MB	256MB+
Cached page TTFB	200-500ms	20-80ms	10-50ms

If cached page TTFB is above 200ms, the server hardware itself is the bottleneck. No amount of WordPress optimization will change that. At that point, the audit’s conclusion is a hosting upgrade recommendation, which is a valid and important finding.

Managed WordPress hosting (Kinsta, WP Engine, Cloudways, GridPane) runs on infrastructure tuned specifically for WordPress: Nginx or LiteSpeed rather than Apache, PHP-FPM rather than mod_php, and server-level page caching that outperforms any plugin-based solution. If shared hosting benchmarks are showing the numbers above, moving to managed hosting typically cuts TTFB by 60-80%.

---

Putting It All Together: The Audit Workflow

Run through the steps in this order every time you inherit a slow WordPress site or notice a performance regression. Each step builds on the one before it.

1. Baseline – Record TTFB, LCP, total page size, and request count before any changes
2. TTFB diagnosis – If TTFB is above 600ms, the root cause is server-side. Focus steps 3, 4, 7, and 10 first
3. Database queries – Install Query Monitor, identify the highest-query-count plugins and slowest individual queries
4. Plugin profiling – Isolate any plugin adding more than 100ms to TTFB via binary deactivation testing
5. Assets – List render-blocking resources, add defer attributes, remove assets loaded on unrelated pages
6. Images – Verify WebP serving, check dimensions match display size, confirm lazy loading is on for below-fold images and off for LCP
7. Caching – Verify page cache, object cache, and browser cache headers are all working
8. CDN – Confirm static assets serve from CDN edge nodes, check for misconfigured caching of dynamic pages
9. Database cleanup – Audit autoloaded options, cap revisions, defragment tables
10. Hosting evaluation – If cached TTFB is above 200ms, the infrastructure needs upgrading before any other fix will matter

---

Tracking Progress After Each Stage

Measure after completing each step – not just at the end. This tells you which specific change had the biggest impact, which is useful for prioritizing work on future sites. Keep a simple log:

Stage Completed	TTFB After	LCP After	PageSpeed After
Baseline	___	___	___
Step 3: Database queries fixed	___	___	___
Step 4: Slow plugin replaced	___	___	___
Step 7: Page cache enabled	___	___	___
Step 6: Images optimized	___	___	___
Final	___	___	___

This tracking approach also helps when reporting work to clients or stakeholders. “TTFB improved from 1.2s to 180ms after enabling Redis object cache and identifying the slow query in the WooCommerce order lookup” is a far more credible deliverable than “I optimized the site.”

---

Related Guides in the TweaksWP Performance Series

This checklist is designed to complement several deeper-dive guides already available on TweaksWP. Once you have identified where the bottleneck is, go to the specific guide for that problem:

• Find and Fix Slow Database Queries in WordPress – SAVEQUERIES, Query Monitor deep dive, EXPLAIN analysis, custom indexes
• WordPress Database Maintenance: OPTIMIZE TABLE, Repair, and Cleanup – Monthly maintenance routine, InnoDB vs MyISAM, WP-CLI automation
• How to Set Up Redis Object Cache for WordPress – Redis installation, configuration, hit ratio monitoring
• How to Limit, Disable, and Clean Up Post Revisions – Revision caps, bulk cleanup, per-post-type control

---

Best WordPress Plugins database cleanup database optimization page speed optimization TTFB

Last modified: March 2, 2026