How to Diagnose a Slow WordPress Website

A slow WordPress site rarely has one obvious cause. It is usually a handful of small problems stacking up: an outdated PHP version, slow database queries, unoptimised images, or a server too small for its traffic. Diagnosis is a skill, not a guessing game — with a repeatable process you can find the bottleneck in an afternoon and fix the right thing first.

This guide walks through that process, from measuring the problem to isolating its cause. It assumes you can access your WordPress admin area and, ideally, your hosting control panel. Before you change anything, make a full backup.

Step 1: Measure Before You Touch Anything

Never optimise on the basis of a feeling. Run a measurement first so you have a baseline to compare against later.

Start with PageSpeed Insights. Enter your homepage URL and test both mobile and desktop. Pay attention to the field data (real-user measurements from the Chrome User Experience Report) as well as the lab data. Field data reflects what your visitors actually experience; lab data is a single simulated load that is useful for debugging. If the two disagree, trust the field data — it is what Google uses for its Core Web Vitals assessment.

Record three numbers: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS). Also note Time to First Byte (TTFB), which tells you how long the server takes to start responding. A TTFB above roughly 800 ms usually points at the server or the database rather than at your theme or images.

Repeat the test on two or three important pages, not just the homepage — problems are often template-specific: a shop page with dozens of product queries behaves very differently from a simple article.

Step 2: Separate the Server From the Site

The most useful question in any speed diagnosis is: is the server slow, or is the site slow? The two have different fixes.

Test TTFB with a simple tool such as curl from your own computer:

curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" https://example.com/

Run it a few times and look at the pattern. If TTFB is consistently high even for a cached page, the server itself — its CPU, memory, PHP version or database — is the bottleneck. If TTFB is fast but the page still takes seconds to finish loading in the browser, the problem is in the front end: render-blocking scripts, large images or too many requests.

Also check your PHP version. WordPress recommends PHP 8.3 or newer, and as of October 2026 the PHP project supports branches 8.2 through 8.5, with PHP 8.2 losing security support on 31 December 2026. A site still running PHP 7.4 or 8.0 is not only slower — newer PHP branches are measurably faster per request — it is also running an unsupported interpreter that receives no security fixes. You can see your PHP version in WordPress under Tools → Site Health → Info → Server. If your host lets you change it, do so on a staging copy first.

Check the Site Health screen itself while you are there (Tools → Site Health → Status). WordPress flags the most common configuration problems for you: missing PHP extensions, an outdated MySQL or MariaDB version, low memory limits and background update failures.

Step 3: Find the Slow Queries

WordPress builds every page from the database, and a single bad query can add seconds. Install the free Query Monitor plugin, activate it, and browse your slow pages while logged in. It adds a toolbar menu showing page generation time, the number of database queries, peak memory usage and the number of external HTTP requests.

Open the Queries panel and sort by time. Look for:

• Slow queries — anything taking a noticeable share of total generation time, especially queries without an index or with LIKE '%...%' patterns on large tables.
• Duplicate queries — the same query run dozens of times, usually by a plugin that does not cache its results.
• Queries grouped by component — Query Monitor attributes queries to the plugin, theme or core component responsible, so you can see exactly which plugin is costing you time.

Common culprits are related-posts plugins that scan the whole posts table, statistics plugins that query on every page load, and page builders that generate heavy queries for every widget. If one plugin accounts for most of the load, test with it deactivated on staging — if the page gets dramatically faster, replace the plugin or contact its developer.

Also check the HTTP API Calls panel. Plugins that call external services (shipping rates, social feeds, licence checks) on every page load can stall rendering if the remote service is slow. A request that times out after several seconds is worse than a slow one.

Step 4: Audit Plugins and the Theme

Deactivating plugins one by one on the live site is risky and slow. The reliable method is a staging copy and a binary search:

1. Copy the site to staging (see how to build a safe WordPress staging workflow).
2. Measure the staging site’s load time.
3. Deactivate half the plugins and measure again.
4. If it got faster, the problem is in that half; if not, it is in the other half. Repeat until you isolate the plugin.

Also deactivate anything you do not actively use, and be suspicious of duplicated functionality: two caching plugins or three slider plugins will fight each other and slow everything down.

Themes deserve the same scrutiny. A theme that loads its own copy of jQuery, several icon fonts, a slider library and a page-builder framework on every page is expensive before your content even appears. Test with a default WordPress theme (such as Twenty Twenty-Five) on staging: if the site becomes dramatically faster, the theme — or the page builder it depends on — is a major part of the problem.

Step 5: Check Images and Front-End Weight

Images are the most common front-end cause of slow WordPress sites, and the easiest to fix.

• Resize before uploading. A 4,000-pixel photo displayed at 800 pixels wastes bandwidth on every visit. Resize to the largest size the layout actually needs.
• Use modern formats. WebP and AVIF files are typically much smaller than JPEG or PNG at the same visual quality. WordPress has supported WebP uploads since version 5.8.
• Compress. Lossy compression at a sensible quality setting is invisible to visitors and can cut file sizes by half or more.
• Lazy-load below-the-fold images. WordPress does this by default for images since version 5.5, but your theme or a plugin may override it. Never lazy-load the hero image — that is usually the LCP element and delaying it hurts your score.
• Set width and height attributes. Missing dimensions cause layout shift, which hurts CLS.

Then look at total page weight in PageSpeed Insights or your browser’s developer tools (Network tab). A page that downloads several megabytes of JavaScript and CSS is slow on mobile connections. Remove unused CSS and JavaScript where you can, defer non-critical scripts, and be honest about third-party embeds: each chat widget, social feed and tracking script is a separate dependency that can delay your page.

Step 6: Check Caching and the Database

Caching is not a fix for a slow site — it hides a slow site — but a correctly configured cache is still essential. Verify that page caching is actually working: load a page twice and check the response headers for a cache hit, or simply compare the second load’s TTFB with the first. If there is no difference, the cache is not engaged.

For logged-in users and dynamic pages, page caching does not apply, so object caching matters more. If your host offers Redis or Memcached, enabling object caching can cut database load dramatically on busy sites. On shared hosting, ask your provider what is available — [TO BE CONFIRMED: whether Offshore Hosting WordPress plans include object caching].

The database itself also needs occasional care. Over time, wp_options accumulates expired transients, post revisions pile up, and spam comments and trashed items bloat tables. A cleanup plugin or a careful wp db optimize via WP-CLI can help — but always back up first.

Step 7: Decide What the Numbers Mean

Once you have the evidence, the fix usually falls into one of four buckets:

If the server is the bottleneck and you have already tuned PHP and the database, the honest answer may be a hosting upgrade rather than another plugin. A CDN can help with static assets and global visitors, but it cannot fix a slow origin server — it only reduces how often visitors need to reach it.

Keep a Record

Write down the baseline numbers, what you changed, and the numbers after each change. Speed work is iterative, and without a record you will re-test the same ideas months later. A simple spreadsheet with the date, the page tested, LCP, INP, CLS and TTFB is enough — and re-measure after every significant change, so regressions are caught while they are still small.

Sources

• Query Monitor — WordPress.org plugin directory: https://wordpress.org/plugin/query-monitor
• WordPress requirements: https://wordpress.org/about/requirements/
• PHP supported versions: https://www.php.net/supported-versions.php
• PageSpeed Insights: https://pagespeed.web.dev/
• WordPress news and release announcements: https://wordpress.org/news/

Sources

• {‘title’: ‘Query Monitor — WordPress.org plugin directory’, ‘url’: ‘https://wordpress.org/plugin/query-monitor’}
• {‘title’: ‘WordPress requirements (PHP and MySQL/MariaDB versions)’, ‘url’: ‘https://wordpress.org/about/requirements/’}
• {‘title’: ‘PHP supported versions and end-of-life dates’, ‘url’: ‘https://www.php.net/supported-versions.php’}
• {‘title’: ‘PageSpeed Insights’, ‘url’: ‘https://pagespeed.web.dev/’}
• {‘title’: ‘WordPress news and release announcements’, ‘url’: ‘https://wordpress.org/news/’}

← All guides · Knowledge Base