WordPress Slow to Load? Diagnose It in the Right Order

WordPress sites slow down for a handful of well-understood reasons, but the mistake most people make is jumping straight to a fix — adding a caching plugin, compressing images — without first confirming what is actually causing the slowness. This guide walks you through a diagnostic sequence that finds the real bottleneck first, so every action you take actually moves the needle.

Start Here: Separate Perception from Measurement

Before touching anything, get a number. "My site feels slow" is not something you can fix. Open Google PageSpeed Insights (pagespeed.web.dev) and run your homepage, your heaviest product or blog page, and — if you have one — your checkout page. Write down:

• Time to First Byte (TTFB) — how long the server takes to start responding
• Largest Contentful Paint (LCP) — when the main visible content finishes loading
• Total Blocking Time (TBT) — how much JavaScript is delaying interactivity
• Page weight — total kilobytes transferred

Also run the same URL in GTmetrix or WebPageTest from a server region close to your actual audience. These tools give you a waterfall chart — a timeline of every request the page makes — which is your most important diagnostic tool. Keep this tab open throughout.

Rule of thumb: If TTFB is above 600ms, the problem is almost certainly server-side — PHP, database, or hosting. If TTFB is fast but LCP is slow, the problem is front-end: images, fonts, or JavaScript.

Layer 1: The Server (TTFB Diagnosis)

A high TTFB means WordPress is spending a long time building the page before sending a single byte to the browser. Work through these in order.

1. Check Whether a Page Cache Is Active

The single biggest TTFB win for most WordPress sites is a page cache that serves pre-built HTML instead of running PHP and a database query on every visit. In your browser, open DevTools → Network, reload the page, click the first HTML document, and look at the response headers. You should see something like X-Cache: HIT, cf-cache-status: HIT, or a similar header from your caching plugin or host. If you see nothing, or a consistent MISS, no cache is being served. Install and configure a page cache — many managed hosts (Kinsta, WP Engine, Pressable) include one at the server level; for shared hosting, WP Super Cache or W3 Total Cache work well. If you want a deeper breakdown of which cache layer to reach for first, see WordPress Caching: Which Layer to Use and When.

2. Test TTFB With Cache Bypassed

Even if caching is on, you need to know how slow the uncached response is, because that determines the ceiling. Add ?nocache=1 or log in as admin (which usually bypasses page cache) and retest. If uncached TTFB is above 2–3 seconds, there is a deeper PHP or database problem.

3. Run a Query Monitor Audit

Install the free Query Monitor plugin. It adds a toolbar item showing how many database queries ran, how long they took, and which plugin or theme generated each one. Look for:

• More than 50–80 queries on a single page load
• Any single query taking more than 100ms
• Queries from plugins you installed but rarely use

A page with 200 database queries from a bloated plugin stack will always be slow, no matter how much caching you pile on top.

4. Check PHP Version

PHP 7.4 runs roughly twice as fast as PHP 5.6 for typical WordPress workloads, and PHP 8.1–8.2 is faster still. In your host's control panel, confirm you are running at least PHP 8.1. If you are on anything below 7.4, updating PHP alone can cut server response time dramatically. Check compatibility before upgrading — our guide Upgrading PHP for WordPress: What Breaks and How to Prepare covers exactly how to do this safely.

5. Evaluate Your Hosting Tier

Shared hosting plans that allocate very little RAM per PHP process will be slow regardless of optimisations. If your site has grown — more traffic, a WooCommerce store, a membership section — but your hosting plan has not, you may have hit a ceiling. Signs: TTFB is consistently slow even with page cache active, the site slows sharply under moderate traffic, or your host's resource usage dashboard shows regular CPU or memory spikes. A move to a managed WordPress host or a VPS with more resources is sometimes the only real fix.

Layer 2: The Database

Even on good hosting, a bloated or unoptimised database can cause slow admin screens, slow front-end loads, and laggy search.

6. Clean Autoloaded Options

Run this query in phpMyAdmin or via a plugin like WP-Optimize:

SELECT option_name, length(option_value) AS size
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size DESC
LIMIT 20;

Every row where autoload = 'yes' is loaded into memory on every single page request. If the total autoloaded data exceeds 1–2MB, or if you see rows from deactivated plugins still sitting there, you have a real drag on performance. Remove orphaned plugin data and, where safe, flip non-essential rows to autoload = 'no'.

7. Prune Post Revisions, Drafts, and Transients

WordPress stores every revision of every post by default. A five-year-old site can have tens of thousands of revision rows that bloat queries. Use WP-Optimize or add define( 'WP_POST_REVISIONS', 5 ); to wp-config.php to cap revisions going forward, then run a one-time cleanup. Expired transients (temporary cached values stored in the database) can also accumulate into hundreds of thousands of rows on busy sites.

Layer 3: Plugins and Themes

Plugins are the most common cause of unexpected WordPress slowdowns because each active plugin adds PHP execution time, potential database queries, and often external HTTP requests.

8. Profile Plugin Impact

With Query Monitor active, note the total page generation time. Then deactivate all plugins except your most essential ones (caching, security), reload and note the time again. If the difference is dramatic, reactivate plugins one at a time, reloading after each, until performance degrades. This is the definitive way to find a slow plugin. For a more structured approach to this process, see Speed Up WordPress: Why Your Site Is Slow and How to Fix It.

9. Check for External HTTP Requests

Some plugins make HTTP requests to third-party APIs on every page load — font providers, analytics endpoints, license verification servers. In Query Monitor, look at the HTTP API Calls panel. Any slow or failing external request adds directly to your TTFB. A plugin making a 2-second call to a licence server on every page is a silent killer.

10. Audit Your Theme

Multipurpose themes (Avada, Divi, Elementor-native themes) often load large CSS and JavaScript bundles even on pages that use none of those features. Check whether your theme loads its full asset stack on every page, or whether you can disable features you are not using. In some cases, moving to a leaner theme or a block-based theme is a more reliable fix than fighting the bundled assets.

Layer 4: Front-End Assets

If TTFB is already fast but LCP or Total Blocking Time is high, the browser is the bottleneck.

11. Audit the Waterfall

In your GTmetrix or WebPageTest waterfall, look for:

• Large uncompressed images — anything above 150KB for a non-hero image is worth compressing and converting to WebP
• JavaScript files that block rendering — scripts loaded in the <head> without defer or async
• Too many separate requests — 80+ individual files are a sign of poor bundling
• Fonts loading from Google Fonts or Adobe Fonts — consider self-hosting fonts to remove the external DNS lookup
• No CDN — static assets (images, CSS, JS) served from your origin server instead of a CDN edge node close to the visitor

12. Confirm Core Web Vitals in Search Console

Google Search Console → Experience → Core Web Vitals shows real-user data for your URLs grouped as Good, Needs Improvement, or Poor. Field data here often reveals pages that test well in a lab but perform poorly for real visitors on mobile connections — which is where most of your traffic actually comes from.

Build a Fix Priority Order

Once you have worked through the checklist, you should have a clear picture of where time is actually being lost. Fix in this order of impact:

1. PHP version and server resources (biggest single lever)
2. Page cache if not already active
3. Database bloat and slow queries identified by Query Monitor
4. Problem plugins contributing disproportionate query or processing load
5. Front-end asset optimisation (images, JS deferral, CDN)

When to Call a Professional

If you have worked through this checklist, made the obvious changes, and the site is still slow — or if Query Monitor is pointing at slow queries deep in a plugin's code that you cannot safely edit — that is a good time to stop experimenting and get a professional audit. Guessing at this stage usually means wasting time on fixes that do not move the bottleneck.

Mend's Speed Pass is a flat-fee performance fix where a senior engineer runs this exact diagnostic, identifies the real bottleneck, and fixes it — with a plain-English report of what changed and why. If you are not sure where to start, a free Diagnosis will triage the site and give you a clear picture before any work begins.

Prevention: Keep It Fast Going Forward

Slowdowns creep in through plugin updates, content growth, and accumulating database waste. A few habits keep performance from regressing:

• Run Query Monitor after every significant plugin or theme update
• Schedule monthly database cleanups (WP-Optimize can automate this)
• Set a Google Search Console alert for Core Web Vitals regressions
• Audit active plugins every quarter — deactivate and delete anything you are not actively using
• Test a staging copy of major updates before pushing to production, so you catch performance regressions before visitors do