# How to Diagnose a Slow WordPress Website

- Link: https://offshorehosting.pk/how-to-diagnose-a-slow-wordpress-website/
- Published: 2026-10-25T10:14:00+00:00
- Author: admin

# 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](https://pagespeed.web.dev/). 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](https://offshorehosting.pk/blog/core-web-vitals-for-wordpress-site-owners)
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:

    ```bash
    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](https://wordpress.org/plugin/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](https://offshorehosting.pk/blog/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:

  |  Finding |  Likely fix |  
   |  High TTFB on every page, even cached |  Server resources, PHP version, or database performance |  
 |  One plugin or theme dominates query time |  Replace or reconfigure that component |  
 |  Fast TTFB, slow full load |  Images, scripts, CSS and third-party embeds |  
 |  Slow only under traffic |  Resources are exhausted — see [how to prepare a website for a traffic spike](https://offshorehosting.pk/blog/how-to-prepare-a-website-for-a-traffic-spike) and [how to size a VPS](https://offshorehosting.pk/blog/how-to-size-a-vps-for-your-application) |

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](https://offshorehosting.pk/blog/cdn-vs-web-hosting-and-when-you-need-both)
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/’}