Why Is My WordPress Site So Slow?

Measure server response time first: if the HTML takes more than a second to arrive, the problem is the server or WordPress itself; if the HTML arrives fast and the page still crawls, the problem is what the page loads. Those two answers lead to completely different fixes, and guessing between them is why most speed work does nothing.

Step 1: split server time from page time

Run this from your own machine, logged out, three times in a row:

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

Then open the same page in a private window with the browser's Network panel open and note when the page becomes usable.

If the numbers were fine last week and are not today, skip to Step 6: a sudden change has a specific cause.

Step 2: the server answers slowly

A high TTFB means the visitor waits while PHP runs and the database is queried before a single byte is sent. The usual reasons, most common first:

• No page cache. Every visit rebuilds the same HTML. Check the response headers for a cache status, as shown in how to check HTTP headers. If there is none and repeat requests are just as slow, caching is the single biggest change available, and choosing a cache plugin starts with whether the host already provides one. On hosting without server-level caching, a plugin such as WP Rocket works with its defaults.
• A cache that is bypassed. A cookie set by a consent banner, analytics script or a plugin's session can make every request look personalised, so the cache never serves it.
• Cheap shared hosting under load. Shared plans throttle CPU and limit PHP workers. The tell is inconsistency: the same page takes 0.4 s, then 3 s, then 0.5 s.
• An old PHP version or a bloated wp_options table with megabytes of autoloaded data.

The full server-side method is in reducing server response time. If the host is the ceiling, comparing hosting is cheaper than months of tuning.

Step 3: the server is fast, the page is not

The HTML arrives quickly and then the browser spends seconds downloading and running everything else. This is also the usual reason a WordPress site is slow on mobile while seeming fine on a desktop.

Open the Network panel, sort by size, then by time:

• Images in the megabytes, served at four times their display size — see optimising images.
• JavaScript from plugins loaded on every page: sliders, form scripts, chat widgets, reCAPTCHA on pages with no form.
• Third-party tags — ads, heat maps, social embeds, video — which often outweigh the whole site.
• Web fonts in six weights when two are used.

Core Web Vitals report this layer per page group, which is how you see whether real visitors are affected; the Core Web Vitals guide explains which metric points at which asset.

Step 4: one page is slow, the rest are fine

When only the homepage or one landing page is slow, the template is the problem, not the site:

• a page builder layout with dozens of nested sections and widgets;
• a slider or video background as the first thing on screen;
• a product grid or post query loading hundreds of items with no pagination;
• an embedded map or feed that waits on an external service.

Compare it with a plain text page on the same site. The difference between the two is exactly what the template costs.

Step 5: slow only when logged in

Logged-in requests are almost never page-cached, so they expose raw PHP and database time. If the front end is fast for visitors but slow for you, that is normal behaviour exaggerated by heavy plugins. Dashboard widgets, plugins checking licences on every admin load and the Heartbeat API are the usual causes — speeding up the WordPress admin covers them.

Step 6: the site is suddenly very slow

A site that was fine and is now extremely slow changed recently. Work backwards:

1. A plugin or theme update. Roll it back on staging and retest.
2. A new plugin. Security plugins running full file scans, SEO plugins rebuilding sitemaps or link indexes, and backup jobs all consume CPU on a schedule.
3. A traffic spike or bot crawl. Check the access log for one IP or user agent making thousands of requests.
4. A host-side change — a migration to a busier server, a PHP downgrade, or an exhausted resource quota.
5. A failing external call. A plugin waiting on an API that has started timing out blocks the whole request.

Disabling plugins in a controlled order is the fastest way to find the one at fault: diagnosing plugin conflicts has the procedure.

Common mistakes

• Testing while logged in and concluding the cache does nothing.
• Installing a speed plugin before measuring, so you never learn which layer was slow.
• Running one test. A single slow result on shared hosting means little; three in a row means something.
• Trusting a single score instead of TTFB and load time, which tell you where to look.
• Fixing images when TTFB is three seconds. The front end cannot start until the HTML arrives.

Verify

Re-run the same curl command and the same Network panel test after each change, logged out and with the cache warm. TTFB should drop to around 200 ms on a cached page (under 0.5 s at worst on shared hosting), and the page should be usable within two to three seconds on a mobile profile. If one number improves and the other does not, the remaining slowness is in the other layer — and the full speed checklist picks up from there.