Why is my WordPress site slow? Common causes and how to fix each one

If you are asking "why is my WordPress site slow", the honest answer is that it is almost never one thing, and guessing wastes money. In most slow sites I look at, the cause sits in one of a few layers: a slow server (high TTFB), no page cache, a heavy theme or page builder, too many plugins doing work on every request, oversized images, third-party scripts, or a bloated database. The fix is to measure first, find the layer that is actually slow, and fix that layer before touching anything else.

Quick answer: Run PageSpeed Insights and look at the field data first, then check server response time (TTFB). If TTFB is high, the problem is hosting, caching, plugins or the database. If TTFB is fine but the page still loads slowly, the problem is images, CSS, JavaScript and third-party scripts. Fix in that order.

Why is my WordPress site slow? Diagnose it in 10 minutes

Before installing another optimization plugin, spend ten minutes finding out where the time goes. You need three readings.

1. PageSpeed Insights: field data first, lab data second. Run your home page and one key inner page (a product, a service page, a blog post) through PageSpeed Insights (opens in a new tab). The top box, "Discover what your real users are experiencing", is field data from the Chrome User Experience Report (CrUX), collected from real Chrome users over the previous 28 days (Google's PSI docs (opens in a new tab)). The score below it is lab data: one simulated load on one device. Field data tells you whether real visitors suffer. Lab data tells you why. A small site often shows no field data at all, which only means there is not enough traffic for CrUX, not that the site is fast.

2. Server response time (TTFB). This tells you whether the slowness happens before the browser receives anything. From any terminal:

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

Run it three or four times. The first request may be slower if the cache was cold. As a rough guide, a cached WordPress page should come back well under half a second from a nearby location. If you consistently see one second or more, the bottleneck is on the server, and no amount of image compression will fix it.

3. Query Monitor on the slow page. Install the free Query Monitor (opens in a new tab) plugin (on staging if you have one), log in, and open the slow page. The admin bar shows page generation time, query count and memory. The "Queries by Component" panel shows which plugin or theme is running the most or slowest database queries, and "HTTP API Calls" shows plugins that call external servers while the page is being built. Those two panels find the culprit on most slow sites.

With those three readings you know which of the causes below to read first.

1. Hosting and a high TTFB

Cheap shared hosting is the most common reason a WordPress site is slow to load, because every uncached request runs PHP and MySQL on a server shared with many other sites. Signs: high TTFB even on a simple page, slow wp-admin, and speed that varies through the day.

How to fix it:

• Check the PHP version under Tools > Site Health > Info > Server. WordPress currently recommends PHP 8.3 or greater (opens in a new tab) and MySQL 8.0+ or MariaDB 10.11+. Old PHP versions are slower and no longer receive security fixes. Switching is usually a setting in the hosting panel; test on staging first and watch the PHP error log for old plugins that break.
• Ask the host what PHP workers, memory limit and storage type your plan has. A busy WooCommerce store on an entry plan simply runs out of PHP workers and visitors queue.
• Pick a data center close to most of your visitors, and put a CDN in front for static files.
• If you have already moved hosts once and TTFB is still high, the problem is probably in the code (plugins, theme, database), not the server. Read on.

2. No page cache, or two caches fighting

Without a page cache, WordPress builds every page from scratch for every visitor: load core, load every plugin, run the theme, query the database. A page cache stores the finished HTML and serves it directly, which is usually the single biggest speed gain on a content site.

Check whether your pages are actually cached by looking at the response headers:

curl -sI https://example.com/ | grep -iE "cache|age|x-litespeed"

Headers such as x-cache: HIT, cf-cache-status: HIT, x-litespeed-cache: hit or a non-zero age mean a cache served the page. No cache headers at all usually means no page cache.

Common mistakes I see:

• Two page caching plugins active at once, or a caching plugin on top of host-level caching. They conflict, and sometimes neither works. Use one: the host's built-in cache if it has one, otherwise one plugin.
• Cache disabled by a cookie. Some plugins set a cookie for every visitor, and many caches bypass any request that carries it. If headers show MISS on every reload, look for this.
• No persistent object cache on a dynamic site. For WooCommerce, membership or LMS sites where many pages cannot be page-cached, a Redis or Memcached object cache cuts repeated database queries. Site Health will suggest one when it thinks your site would benefit.

3. Too many plugins, or one heavy plugin

The number of plugins matters less than what they do (SEO plugins are a common question; Yoast vs Rank Math compares their footprint). Thirty small, well-written plugins can be faster than one plugin that runs an expensive query on every page load. So "my WordPress website is very slow, should I delete plugins?" is the wrong question. The right question is which plugin costs the most.

How to find the culprit:

1. Open Query Monitor's Queries by Component and sort by time. A plugin with hundreds of queries, or one slow query, stands out.
2. Check HTTP API Calls. A plugin that calls a license server or an external API during page generation can add a second or more, especially if that server is slow.
3. On staging, deactivate plugins one at a time (or all, then reactivate in groups) and remeasure TTFB with the curl command above. With WP-CLI: wp plugin deactivate plugin-slug.
4. Look at what each heavy plugin loads on the front end. Sliders, form builders, popups and social feeds often load their CSS and JavaScript on every page, even where they are not used.

Then decide: replace the plugin with a lighter one, configure it to load only where needed, or replace it with a few lines of custom code in a small custom plugin. Delete plugins you no longer use rather than leaving them deactivated, which also reduces your attack surface.

4. Heavy theme or page builder

Multipurpose themes and page builders make building pages easy, and they pay for it in markup. A section that needs three HTML elements might output fifteen nested wrappers, plus the builder's CSS and JavaScript for every widget type. That slows rendering, increases the DOM size and hurts interaction responsiveness. If you are building from a design file, my Figma to WordPress guide compares page-builder, block theme and custom theme builds.

What helps, without a rebuild:

• Turn on the builder's own performance settings (optimized asset loading, reduced markup) and disable widgets and modules you never use. Test each change on staging; some settings break older layouts.
• Avoid nesting sections inside sections. Flatter layouts render faster.
• Do not load a second builder or an add-on pack for one widget.
• Use system fonts or self-host one or two font families with only the weights you use.

If the theme is the root problem, a lighter block theme or a custom theme built for your actual pages is usually faster than any amount of plugin tuning. I compare those options in WordPress vs a custom website.

5. Images and video

Oversized images are the most common cause of a slow Largest Contentful Paint (LCP), because the biggest element above the fold is usually a hero image.

• Resize before upload. A 4,000 pixel photo shown at 1,200 pixels wastes most of its bytes. WordPress creates smaller sizes, but the theme has to use them through srcset.
• Serve WebP or AVIF. WordPress supports uploading WebP (since 5.8) and AVIF (since 6.5); an image optimization plugin or your CDN can convert existing JPEGs.
• Do not lazy-load the hero image. WordPress adds loading="lazy" to images by default and tries to skip the first one, but some themes and plugins lazy-load everything, which delays LCP. The LCP image should load eagerly, ideally with fetchpriority="high".
• Never self-host background videos on the home page. Use a poster image and load the video only on click, or embed it through a lightweight facade.

6. Render-blocking CSS and JavaScript

When PageSpeed Insights says "Eliminate render-blocking resources" or "Reduce unused JavaScript", it means the browser has to download and process files before it can show the page. On WordPress these come from the theme, the builder and every plugin that enqueues assets globally.

Fixes, in order of safety:

1. Remove assets from pages that do not need them (a form plugin's files only on the contact page, a slider's files only on the home page). Query Monitor's Scripts and Styles panels list each file with its handle.
2. Defer non-critical JavaScript. Since WordPress 6.3, scripts can be registered with a loading strategy, for example wp_enqueue_script( 'my-script', $src, array(), '1.0', array( 'strategy' => 'defer' ) ).
3. Let a performance plugin combine critical CSS and delay non-essential scripts, then test forms, menus, carts and checkout carefully. Aggressive "delay all JavaScript" settings are the most common way speed work breaks a site.

Heavy JavaScript also hurts responsiveness after the page loads. That is a separate metric (INP), and I cover it step by step in how to improve INP on WordPress.

7. Third-party scripts

Chat widgets, tag managers, ad scripts, heatmaps, review badges, social embeds and multiple analytics tools all download code from other servers and run it on your visitors' devices. You do not control how fast those servers are or how much JavaScript they run.

• List every third-party domain in the browser's Network panel. You will often find tools nobody uses any more.
• Audit your tag manager container. Old conversion pixels and duplicate analytics tags pile up over the years.
• Load chat widgets on interaction (a static "Chat with us" button that loads the real widget on click).
• Keep one analytics tool unless you have a real reason for two.

8. Database bloat and autoloaded options

Every WordPress request loads all "autoloaded" options from the wp_options table into memory. Plugins often store large data there and leave it behind after you uninstall them. Since WordPress 6.6, Site Health shows a critical issue when autoloaded options exceed 800 KB (make.wordpress.org (opens in a new tab)).

Check the total size and the biggest offenders with WP-CLI:

wp option list --autoload=on --format=total_bytes
wp option list --autoload=on --fields=option_name,size_bytes | sort -n -k 2 | tail -20

Or with SQL (adjust the wp_ prefix to yours):

SELECT option_name, LENGTH(option_value) AS bytes, autoload
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto')
ORDER BY bytes DESC
LIMIT 20;

Option names usually tell you which plugin created them. Leftovers from deleted plugins can be removed; options from active plugins can sometimes be switched to not autoload. Back up the database first, every time.

Other common bloat: thousands of post revisions, expired transients, spam and trashed comments, and orphaned post meta. To clean safely:

wp db export before-cleanup.sql
wp transient delete --expired
wp post list --post_type=revision --format=count

To cap future revisions, add define( 'WP_POST_REVISIONS', 10 ); to wp-config.php.

9. Slow WP admin

A slow dashboard has different causes from a slow front end, because admin pages are never page-cached. If you want to know how to speed up WordPress admin specifically:

• Heartbeat API. The editor and dashboard send regular admin-ajax.php requests. On a weak server with several editors logged in, that adds up. You can slow it down:

add_filter( 'heartbeat_settings', function ( $settings ) {
    $settings['interval'] = 60; // seconds
    return $settings;
} );

• Dashboard widgets and admin notices from plugins that call external servers on every admin page load. Query Monitor's HTTP API Calls panel shows them.
• Large post lists with many custom columns, filters or meta queries. WooCommerce order lists on older storage are a common case (see below).
• WP-Cron. On low-traffic sites, scheduled tasks run during page loads. Switching to a real server cron (define( 'DISABLE_WP_CRON', true ); plus a cron job that calls wp cron event run --due-now every few minutes) removes that delay.

10. WooCommerce-specific slowness

WooCommerce stores are harder to speed up because cart, checkout and account pages cannot be served from page cache, and logged-in customers bypass the cache for most pages.

• Cart fragments. The wc-cart-fragments script sends an AJAX request on page load to update the mini cart. Since WooCommerce 7.8 it is no longer loaded on every page by default, only where a cart widget needs it (WooCommerce developer blog (opens in a new tab)). Many themes still enqueue it everywhere, so check.
• Order storage. High-Performance Order Storage (HPOS) keeps orders in dedicated tables instead of wp_posts. New stores use it by default; older stores may still need to migrate, which makes order admin and reporting faster.
• Sessions and scheduled actions. Check the size of the wp_woocommerce_sessions table and the Action Scheduler tables. Thousands of failed or pending actions usually point to a broken integration.
• Product filters and search. Layered navigation on large catalogs runs expensive queries. A dedicated search and filter solution or proper indexing helps.
• Cache exclusions. Make sure cart, checkout and my account are excluded from page cache, and nothing else is. Caching plugins sometimes exclude far more than needed.

Say a store has 2,000 products and a slow category page: Query Monitor will usually show whether the time goes to the product query, a filter plugin or a related products widget, and that tells you exactly where to work.

How to speed up a WordPress website in the right order

This is my answer to how to speed up WordPress website performance without breaking anything. Work in this order:

Retest after each step, keep notes, and give field data a few weeks to catch up, because CrUX is a 28-day rolling window.

When to call a professional

Call someone when TTFB stays high after a hosting change, when the slow component is your theme or a plugin you cannot replace, when the site is a WooCommerce store where checkout cannot break, or when you have already tried two optimization plugins and are still guessing. A proper WordPress speed optimization job starts with the same measurements above, fixes the cause, and documents what changed so it stays fast. Ongoing WordPress maintenance then stops new plugins and updates from slowly undoing that work.

Frequently asked questions

Why is my WordPress site so slow all of a sudden?

A sudden slowdown usually follows a change: a plugin or theme update, a new plugin, a traffic spike, a hosting change, or a hack injecting code (the WordPress hacked redirect guide shows how to find it). Check what changed in the last few days, look at the PHP error log, and run Query Monitor on a slow page. If nothing changed on your side, ask the host whether the server is overloaded.

Do too many plugins slow down WordPress?

Plugins slow WordPress down when they do expensive work on every request, not simply because there are many of them. One poorly written plugin can cost more than twenty light ones. Measure with Query Monitor before deleting anything.

Why is my WordPress site slow to load only for the first visitor?

That is usually a cache that expired or was cleared. The first request builds the page and stores it; later visitors get the cached copy. Cache preloading (most caching plugins offer it) rebuilds pages in the background so real visitors rarely hit an empty cache.

Will a caching plugin fix a slow WordPress site?

A caching plugin fixes a slow server response for cached pages, which is often the biggest win. It does not fix oversized images, heavy JavaScript, a slow admin or uncached WooCommerce pages. Treat caching as one step, not the whole fix.

If you have worked through this list and the site is still slow, I can find the cause and fix it as part of a WordPress speed optimization project.