Why is my WordPress site slow? Causes and fixes

A slow WordPress site almost always comes down to one of four things: a server that takes too long to build each page, missing page caching, too much work done by plugins and the theme, or heavy images and scripts in the browser. The fix is to find out which of these is actually hurting you, then work through them in order, starting with the server response and ending with front-end polish.

Measure before you change anything

Guessing is the most expensive way to speed up WordPress. Before you deactivate plugins or switch hosts, get a baseline you can compare against later.

• Real-user data: run your URL through corewebvitals.page. If your site has enough traffic, it shows field data from real Chrome users for LCP, INP and CLS. That is what Google uses for page experience.
• Lab data: the Lighthouse section below it is a single simulated load. It is useful for spotting causes, but the score moves from run to run.
• Server response: check how long the HTML itself takes.

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

Run it a few times and for several page types: the homepage, a blog post, a category archive. If the first byte already takes more than about a second, the problem sits on the server side, and no image plugin will fix it. web.dev suggests aiming for a TTFB of 0.8 seconds or less as a rough guide.

For a deeper walkthrough of lab versus field data and how to run a fair before-and-after test, see how to measure website speed properly.

Hosting and server response time

Every uncached WordPress request boots PHP, loads WordPress core, all active plugins and the theme, and runs dozens to hundreds of database queries. How fast that happens depends heavily on the server.

Signs your hosting is the bottleneck

• TTFB is high even on simple pages with little content.
• The site gets noticeably slower in peak hours or during a newsletter send.
• The wp-admin area is sluggish, even though it has nothing to do with front-end assets.
• Your host's dashboard shows CPU or memory limits being hit.

What you can do

• Update PHP. Newer PHP versions are generally faster and still receive security fixes. Check which version your host offers and test your site on the newest one supported by your plugins.
• Add a persistent object cache. Redis or Memcached keeps the results of repeated database queries in memory. Many managed hosts offer it as a switch; it helps most on dynamic pages and in wp-admin.
• Upgrade the plan or the host if the server is simply undersized for your traffic. Sometimes this really is the right answer, and no amount of plugin tuning replaces enough CPU.

If response time is your main issue, the dedicated guide on reducing TTFB goes into server, application and edge fixes step by step.

Page caching

Page caching is the single biggest lever for most WordPress sites. Instead of building the same page with PHP and MySQL for every visitor, a cached copy of the finished HTML is served directly. The WordPress developer handbook has a good overview of the different cache layers.

You have three common options:

These layers can work together. What matters is that anonymous visitors get cached HTML, and that pages which must stay personal are excluded.

What must not be cached

• Logged-in users and wp-admin (WordPress sets login cookies, and most caches bypass on them).
• Comment previews and password-protected posts.
• Cart, checkout and account pages if you run a shop. The WooCommerce speed guide covers these rules in detail.

Check whether caching works

Look at the response headers. Most caches add a header that shows a hit or a miss:

curl -sI https://example.com/ | grep -i -E "cache|age"

If every request shows a miss, or there is no cache header at all, something is bypassing the cache. Typical culprits are a plugin setting a cookie on every visit, Cache-Control: no-cache headers sent by a security plugin, or query strings from tracking links.

Plugins and themes

The number of plugins matters less than what they do. A single badly built plugin can add more load than twenty small ones.

Find the expensive ones

• Install Query Monitor on a staging copy. It shows database queries, slow queries, HTTP API calls and hooks per plugin for every page load.
• Look for plugins that make external HTTP requests on page load (license checks, social counters, remote fonts). These block the page while waiting for another server.
• Deactivate suspects one at a time on staging and measure TTFB again. Don't do this on a live shop.

Common patterns that slow sites down

• Page builders that load their full CSS and JavaScript on every page, even where they are not used.
• Sliders, popups and chat widgets that load several scripts above the fold.
• Related-posts and statistics plugins that run heavy queries on every request.
• Multiple plugins doing the same job (two SEO plugins, two caching plugins).

A lighter theme often helps more than any optimization plugin. If your theme ships with a large framework you barely use, that code still runs on every page.

Images and media

Images are usually the largest part of a WordPress page by weight, and the hero image is often the element that decides your LCP.

• Upload sensible sizes. A 4,000-pixel photo from a phone does not belong in an 800-pixel content column. WordPress creates smaller sizes and uses srcset, but only if the theme outputs them properly.
• Use modern formats. WebP and AVIF are much smaller than JPEG and PNG at similar quality.
• Lazy-load below the fold, not above it. WordPress adds loading="lazy" automatically, but lazy-loading the hero image delays LCP. Make sure the main image loads immediately.
• Set width and height so the browser reserves space and the layout does not jump (CLS).

The guide to optimizing images for the web explains formats, sizing and loading strategy in more depth.

Database and background tasks

Older WordPress sites collect clutter that slows every uncached request.

• Autoloaded options: plugins store settings in wp_options, and entries marked as autoload are read on every request. Deleted plugins often leave large entries behind. Site Health in recent WordPress versions warns when autoloaded data gets too big.
• Expired transients and post revisions bloat tables. Clean them up with a maintenance plugin or WP-CLI, after a backup.
• WP-Cron runs scheduled tasks on normal page views by default. On busy sites, disable it in wp-config.php and trigger it with a real server cron job instead:

define( 'DISABLE_WP_CRON', true );

• Heartbeat API: open editor tabs send requests to admin-ajax.php at regular intervals. On weak hosting this adds up; some performance plugins let you reduce the frequency.

Fix it in the right order

Working in the right order saves time, because the early steps often make later ones unnecessary.

1. Measure TTFB and Core Web Vitals on your most important page types.
2. Fix the server response: PHP version, object cache, enough resources.
3. Enable page caching for anonymous visitors and verify the cache headers.
4. Remove or replace heavy plugins and trim what the theme loads.
5. Optimize images: size, format, no lazy-loading on the hero.
6. Clean up the database and move WP-Cron to a server cron.
7. Measure again with the same tools and pages, and compare.

If your visitors come from several countries, the distance to your server also adds latency to every request, even with good caching on the origin. That is where an edge cache helps.

How fast.site helps

fast.site sits in front of your existing WordPress hosting. You keep your host and your site; you add your domain in the dashboard and point your nameservers to fast.site. After that, fast.site manages your DNS, so make sure all existing records, including MX records for email, are in the fast.site DNS zone.

Anonymous page views are then served by Fast Edge Cache™ from edge servers close to your visitors, in the regions available on your plan. A cache HIT never reaches your origin, which takes load off the server in peak hours. Logged-in sessions and wp-admin should bypass the cache, and the fs-cache response header shows HIT, MISS or BYPASS so you can check each page yourself. After publishing, you can purge single URLs in the dashboard or via the API, and a cache warmer keeps key pages primed.

On the front end, fast.site can convert JPEG and PNG to WebP on the fly (AVIF depending on plan) and optionally preload the hero image and add missing image dimensions. See the WordPress page and the caching docs for details.

Measure your site before and after with the same tests. You can try it with a free 7-day trial, no credit card required.

FAQ

Why is my WordPress site slow only when I'm logged in?

Most page caches bypass logged-in users, so every page you view is built fresh by PHP. The admin bar and editor scripts add extra work. Test in a private window to see what visitors actually get.

Do too many plugins slow down WordPress?

The count matters less than what each plugin does. A few heavy plugins that run slow queries or call external services on every request cost more than many small ones. Use Query Monitor on a staging site to find the expensive ones.

Is a caching plugin enough?

For a small site with local visitors, a well configured caching plugin on decent hosting is often enough. If your visitors are spread across regions, or you see traffic spikes, an edge cache in front of the server adds distance savings and takes load off the origin.

Why is my WordPress site slow in the admin area?

wp-admin is never page cached, so it shows the raw speed of your server, plugins and database. Slow admin pages usually point to undersized hosting, a missing object cache, large autoloaded options or a plugin doing heavy work on every admin request.