Why Your WordPress Site Is Slow (And How to Fix It in 30 Minutes)

Last Tuesday, a client called us because their WooCommerce store took 11.3 seconds to load. Eleven seconds. Their Google Ads were burning through EUR 1,800/month driving traffic to a page that 73% of visitors abandoned before it even finished rendering. We got it down to 2.1 seconds in under 30 minutes without changing their hosting plan, their theme, or a single line of PHP. Here's exactly what we did, and how you can do the same.

We debug slow WordPress sites almost daily -- it comes with the territory when you manage hosting for 200+ WordPress installations. The causes are almost always the same five things, and the fixes are almost always straightforward. Let's walk through them in order of impact.

Step 1: The Plugin Audit (8 Minutes)

Go to your Plugins page right now and count. If you have more than 25 active plugins, you almost certainly have a problem. Our client from Tuesday? Forty-one active plugins. Twelve of them were deactivated but still installed (which still affects database size and sometimes loads assets).

Plugins to Remove Immediately

These are the repeat offenders we see on almost every slow site:

• Broken Link Checker -- queries every post and page continuously. We've seen it add 3-5 seconds to admin page loads and spike database CPU. Use an external tool like Ahrefs or Screaming Frog for link checking.
• Jetpack (the full suite) -- it loads dozens of modules whether you use them or not. If you only need stats, use a lighter alternative. If you need specific features, use the individual Jetpack modules plugin instead.
• Revision control plugins -- if they're not configured, WordPress stores every revision of every post forever. Add define('WP_POST_REVISIONS', 5); to wp-config.php and delete the plugin.
• Social sharing plugins that load 15 platform scripts -- each one adds an external HTTP request. Use a lightweight option like Social Snap or just manually code share links.
• Multiple SEO plugins running simultaneously -- we've seen sites with both Yoast and Rank Math active. They conflict and both inject schema markup, meta tags, and sitemaps. Pick one.
• WPBakery or other legacy page builders you're not actively using -- if you switched to Elementor or Gutenberg but WPBakery is still active, it's loading shortcode parsers and assets on every page.

How to Test Plugin Impact

Deactivate all plugins. Test load time. Reactivate one at a time, testing after each. Tedious? Yes. But it gives you hard numbers. We did this for our Tuesday client and found that 3 plugins accounted for 6.4 seconds of the 11.3-second load time:

1. A "coming soon" plugin that was no longer needed but was still running its CSS/JS on every page: +1.8s
2. An analytics plugin making 4 external API calls on every page load: +2.3s
3. A premium slider plugin loading a 2.4 MB JavaScript file on every page, not just pages with sliders: +2.3s

Removed all three. Load time dropped from 11.3 to 4.9 seconds without touching anything else.

Step 2: Image Optimization (7 Minutes)

Images are the single largest component of most WordPress pages by file size. The average WordPress page we audit serves 4-8 MB of images. It should be 400-800 KB.

The Quick Fix

Install ShortPixel or Imagify (both offer free tiers). Run bulk optimization on your media library. ShortPixel's "Glossy" compression reduces file sizes by 60-80% with no visible quality loss. We've run it on thousands of images and have never had a client notice the difference visually.

The Proper Fix

• Convert to WebP format. WebP images are 25-35% smaller than JPEG at equivalent quality. ShortPixel and Imagify both do this automatically. WordPress 5.8+ has native WebP support.
• Set up lazy loading. WordPress 5.5+ includes native lazy loading (loading="lazy" on images below the fold). Verify it's working -- some themes override it.
• Specify image dimensions. Every <img> tag should have width and height attributes. Without them, the browser can't reserve space, causing layout shifts that hurt Core Web Vitals scores.
• Don't upload 4000px images for a 600px container. This sounds obvious, but we find it on every third site we audit. Someone uploaded the raw camera image and WordPress is serving a 4000x3000 file that gets CSS-resized to 600x400. That's 10x more data than necessary.

Actual Results

On our Tuesday client's site, bulk image optimization reduced the total page weight from 8.7 MB to 1.4 MB. Load time went from 4.9 seconds (after plugin cleanup) to 3.1 seconds.

Step 3: Database Cleanup (5 Minutes)

WordPress databases accumulate cruft like a garage accumulates boxes. Post revisions, auto-drafts, trashed items, transient options, orphaned metadata from deleted plugins -- it all adds up.

The 5-Minute Cleanup

Install WP-Optimize (free). Run these operations:

1. Clean post revisions -- our client had 12,847 revisions across 340 posts. That's 12,847 unnecessary database rows.
2. Clean auto-drafts -- 287 auto-drafts taking up space.
3. Clean trashed posts and comments -- if it's in the trash, you don't need it in the database.
4. Clean transient options -- expired transients pile up. We found 3,200 expired transients.
5. Optimize database tables -- equivalent to running OPTIMIZE TABLE on every table. Reclaims fragmented space.

Total database size went from 847 MB to 124 MB. That's not a typo.

The wp-config.php Additions

Add these lines to prevent future bloat:

define('WP_POST_REVISIONS', 5);
define('EMPTY_TRASH_DAYS', 14);
define('WP_MEMORY_LIMIT', '256M');

Five revisions per post is plenty for an undo history. Trash auto-emptying at 14 days prevents accumulation. And 256 MB memory gives WordPress enough headroom for complex pages without hitting limits.

Database Queries to Watch

If you have phpMyAdmin access (most hosting control panels include it), run:

SELECT option_name, LENGTH(option_value) as size
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size DESC
LIMIT 20;

This shows you the largest autoloaded options. Autoloaded options are loaded on every single page request. We regularly find plugins that store megabytes of data in autoloaded options -- serialized arrays, cached API responses, log data. Anything over 100 KB in autoloaded options is a red flag.

On one client site last year, a single abandoned plugin had stored 14 MB of serialized data in a single autoloaded option. Every page load was deserializing 14 MB of data that nothing used. Removing that one row cut average response time by 400ms.

Step 4: Caching (7 Minutes)

If you're not using a caching plugin, every page request runs the full WordPress PHP execution and database query cycle. For a typical page, that's 20-50 database queries and 200-500ms of PHP processing -- per visitor, per page.

Our Recommendation: WP Super Cache or LiteSpeed Cache

If you're on an Apache/Nginx server: Install WP Super Cache (free, by Automattic) or W3 Total Cache. WP Super Cache is simpler and more reliable for most sites.

If you're on a LiteSpeed/OpenLiteSpeed server: Install LiteSpeed Cache. It integrates with the server's built-in cache engine and is significantly faster than any other option on LiteSpeed hosting. Since we run OpenLiteSpeed on our hosting infrastructure, this is what we install for every client.

Essential Cache Settings

Regardless of which plugin you use:

1. Page caching: ON. This is the big one. Static HTML files served directly, bypassing PHP entirely. Speed improvement: 60-80% on typical WordPress sites.
2. Browser caching: ON. Sets proper Cache-Control and Expires headers so returning visitors don't re-download CSS, JS, and images.
3. Object caching: ON (if your server supports Redis or Memcached). Caches database query results in memory. Worth 100-300ms per page load on database-heavy sites.
4. Minify CSS and JS: ON, but test carefully. Minification removes whitespace and comments. It occasionally breaks things -- if your site looks wrong after enabling it, disable JS minification first (CSS minification rarely causes issues).
5. GZIP/Brotli compression: Verify it's active. Most modern servers enable this by default, but check. An uncompressed 200 KB CSS file becomes 30 KB with GZIP.

Cache Exclusions

Always exclude:

• WooCommerce cart, checkout, and my-account pages
• Any page with personalised content
• Admin pages (WordPress excludes these by default)

The Result

After enabling LiteSpeed Cache with page caching, browser caching, and object caching (Redis), our client's load time went from 3.1 seconds to 2.1 seconds. For a WooCommerce site with 1,200 products, that's excellent.

Step 5: Quick Server-Side Wins (3 Minutes)

These take almost no time but can make a noticeable difference:

PHP Version

Check your PHP version in your hosting control panel or add <?php phpinfo(); ?> to a temporary file. If you're on PHP 7.4 or below, upgrade to PHP 8.1 or 8.2. PHP 8.x is 15-25% faster than 7.4 for WordPress workloads. We still find clients running PHP 7.2 -- which is not only slow but hasn't received security patches since November 2019.

Disable WP-Cron

WordPress runs a pseudo-cron on every page load to check for scheduled tasks. Replace it with a real server cron job. Add to wp-config.php:

define('DISABLE_WP_CRON', true);

Then set up a server cron job to hit wp-cron.php every 15 minutes. This removes the overhead of checking scheduled tasks on every visitor's page load.

External Resources

Check how many external domains your site connects to. Each one requires a DNS lookup, TCP connection, and TLS handshake. Common offenders: Google Fonts (self-host them instead), Facebook Pixel, multiple analytics scripts, live chat widgets, and embedded content.

Use the dns-prefetch and preconnect resource hints for external domains you can't eliminate:

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="dns-prefetch" href="https://fonts.googleapis.com">

The Before and After

Here's our Tuesday client's journey in 30 minutes:

From 11.3 seconds to 1.9 seconds. Their Google PageSpeed Insights score went from 23 to 84 on mobile. Their Ads bounce rate dropped from 73% to 41% within the first week.

When 30 Minutes Isn't Enough

Sometimes the problem is deeper. If you've done everything above and your site is still slow:

• Your theme is the problem. Some premium themes load 1-2 MB of CSS and JavaScript regardless of what features you use. Test with the default Twenty Twenty-Four theme. If it's fast, your theme is the bottleneck.
• Your hosting is genuinely undersized. A shared hosting plan with 512 MB RAM and a crowded server will be slow no matter what you do. Check your server response time (TTFB) -- if it's over 600ms before any WordPress processing, the server is the constraint.
• You have a rogue plugin making uncached API calls. Use the Query Monitor plugin to identify slow database queries and slow HTTP requests on each page load.

For most WordPress sites, though, the five steps above will get you where you need to be. We run them as the first diagnostic on every slow site ticket we receive, and they resolve the issue about 80% of the time without needing to dig deeper.