Why Your WordPress Site Is Slow (and How to Fix It in the Right Order)

Speed work fails when it starts with a plugin instead of a measurement. Installing three caching plugins on a slow server makes the site more fragile without fixing the actual bottleneck. When people ask why your WordPress site is slow, the honest answer is almost always "we never measured it properly".

Work through these stages in order. Each one has a measurable outcome, so you always know whether it helped.

Stage 1: Measure before you change anything

Use PageSpeed Insights for field data and a lab test, then check time to first byte (TTFB) separately. TTFB measures the server, not the browser, and it is where most slow WordPress sites actually lose their time.

• TTFB under 200 ms — server is healthy; optimise the front end.
• TTFB 200–600 ms — caching or hosting can improve.
• TTFB over 600 ms — fix hosting or database before touching plugins.

Stage 2: Fix the server and the database

Install a query-monitoring plugin in staging and look for slow queries. Common culprits are unindexed meta queries from page builders and bloated wp_options tables from abandoned plugins.

Then check your PHP version. Moving from PHP 7.4 to 8.2 is often the single largest improvement available, and it is free. Ensure opcache is enabled and object caching (Redis) is available if your plan supports it.

Stage 3: Page caching that matches your stack

If your host runs LiteSpeed, use LSCache rather than a generic page cache. If it runs Nginx, use FastCGI cache or a host-provided cache. Two caching layers fighting each other produce stale pages and mysterious logins, so choose one.

Exclude cart, checkout and account pages from the cache. Cache the rest aggressively.

Stage 4: Images, the reliable 30–60% win

Images are usually the largest bytes on the page and the easiest to fix:

1. Resize images to the maximum size they are displayed at, not the size they were uploaded at.
2. Convert to WebP or AVIF, keeping JPEG as a fallback only if you must.
3. Add width and height attributes so the layout does not shift.
4. Lazy-load everything below the fold; never lazy-load the hero image.

Stage 5: Fonts and third-party scripts

Each web font family can cost 100–300 ms. Self-host one family, subset it to the characters you use, and preload the single weight used above the fold. For third-party scripts — chat widgets, pixels, review badges — load them after interaction or defer them. A chat bubble that costs 400 ms of main-thread time on every page load is rarely worth it.

Stage 6: Trim plugins with evidence

Do not count plugins; measure them. Deactivate plugins one at a time in staging and re-test TTFB and Total Blocking Time. Anything that changes nothing can usually go.

What "fast" actually looks like

• LCP under 2.5 seconds on mobile field data
• INP under 200 milliseconds
• CLS under 0.1
• TTFB under 400 milliseconds on a warmed cache

A realistic order of operations

Server and PHP, then one caching layer, then images, then fonts, then scripts, then plugins. Re-measure after every stage and keep a short log. In our experience this order reliably takes a typical business site from four or five seconds to under two.

Where WordPress itself slows you down

Core WordPress is fast. Slowness usually comes from the ecosystem: page builders that load a second copy of jQuery, plugins that query the database on every request, and themes that ship every Google font weight. The WordPress project publishes official performance guidance that is worth reading once before installing a stack of optimisation plugins.

Two specific traps deserve attention:

• Autoloaded options. Every option marked autoload is loaded on every request. A plugin that leaves large rows behind quietly taxes every page.
• REST and admin-ajax calls. Widgets that poll admin-ajax.php turn a static page into a database workload. Cache them or load them on interaction.

When to stop optimising and change hosts

If TTFB stays above 600 ms on a warmed cache after fixing PHP, caching and the database, the server is the ceiling. Shared hosting enforces CPU and entry-process limits that no plugin can bypass. At that point compare plans with explicit NVMe storage, LiteSpeed or Nginx, and a documented CPU allowance.

If the server itself is the ceiling, compare WordPress hosting plans built on LiteSpeed and NVMe storage, or read more performance guides. Verify improvements with Google's PageSpeed Insights before and after every change.