5 WordPress Performance Issues I Fix Every Week (And How You Can Too)

I've audited a lot of WordPress sites for clients who complained their pages felt slow. The same five things come up almost every time. None of them are exotic. All of them get worse quietly. None of them fix themselves.

Why it matters

Every second on page load costs conversions. Industry estimates put the hit at roughly 7% per second on e-commerce; even with generous rounding, a slow site is money left on the table. For a $100K/month store, a single second is $7K/month. For a service business, it's leads that never call.

I've seen 8-second WordPress home pages. All of them fixable, but only once you know where to look.

1. Database bloat

WordPress databases accumulate junk. Spam comments, post revisions (default: unlimited), expired transients, orphaned metadata from plugins that got uninstalled but left their tables behind. I recently audited a 2-year-old site with a 400MB database. Actual content was 50MB.

Start with a size check by table:

SELECT
    table_name AS 'Table',
    ROUND(((data_length + index_length) / 1024 / 1024), 2) AS 'Size (MB)'
FROM information_schema.TABLES
WHERE table_schema = 'your_database_name'
ORDER BY (data_length + index_length) DESC;

Sort by size, look at what's inflating. Common suspects: wp_options with autoloaded transient data, wp_postmeta from a form plugin that never cleans up submissions, wp_comments with 40,000 spam rows.

Cleanup tools like WP-Optimize handle the basics. For wp_options autoload issues, do it manually with SQL and measure query time before and after. One client's site dropped from 6.2s to 3.8s just from database cleanup and setting WP_POST_REVISIONS to a sane number in wp-config.php.

2. Unrestrained images

The most common thing I see is a 5MB hero image loading on mobile. A photography portfolio I inherited had 47 images totaling 180MB on the homepage. On 4G, that's a coffee break to load.

Three fixes, in order of leverage.

WebP conversion. WordPress supports the format if you register the MIME type:

// functions.php
function add_webp_support($mimes) {
    $mimes['webp'] = 'image/webp';
    return $mimes;
}
add_filter('upload_mimes', 'add_webp_support');

Then batch-convert the existing library (any WebP plugin will do it with JPEG fallback for older browsers).

Responsive sizes. WordPress generates them automatically but only if the theme uses wp_get_attachment_image() or the block editor's image block. Sites hand-coded three years ago often bypass this and serve one giant asset to every screen.

CDN with image transforms. Cloudflare's free tier resizes and reformats on the fly if you enable Polish and Mirage. Zero code changes, immediate weight reduction.

An e-commerce client I worked with went from 8.2MB homepage weight to 1.4MB. Load time improved by 65%.

3. Plugin overload

I audited a small business site running 47 active plugins. One was a full e-commerce suite, active because someone had briefly considered selling something two years ago and never turned it off. The contact form was a separate plugin. So was the "recent posts" widget. And the newsletter. And the redirects. And the schema markup.

The audit is dumb but works: list every plugin, deactivate them one at a time, measure page load between each. The ones with big TTFB improvements are the culprits.

Common offenders:

• Page builders (Elementor, Divi) shipping 2MB+ of CSS and JS to render a landing page a static HTML file would render in 50KB
• Social sharing plugins loading 20+ networks nobody uses
• Two SEO plugins because someone installed Yoast, then someone else installed Rank Math, and nobody disabled the other
• Backup plugins scheduled during peak hours

Removing 12 plugins from that 47-plugin site dropped Time to First Byte from 2.1s to 0.8s.

4. No caching, or worse, wrong caching

About 40% of the sites I audit have no caching at all. Another 30% have caching configured in a way that actively hurts them, most commonly a WordPress caching plugin fighting a server-level cache, both trying to store the same responses with different invalidation rules. Every deploy purges one but not the other. Every editorial change bypasses one but is stuck in the other.

The stack that works for most WordPress sites:

• Server level: Nginx FastCGI cache (or Apache mod_cache). Serves static HTML for cached responses without touching PHP.
• Application level: Redis object cache for query results. Cuts database round-trips on complex pages.
• Browser level: proper Cache-Control headers on static assets.
• CDN: Cloudflare or similar in front of everything for edge caching.

Minimum Nginx FastCGI cache config:

location ~ \.php$ {
    fastcgi_cache_valid 200 60m;
    fastcgi_cache_valid 404 10m;
    fastcgi_cache_bypass $skip_cache;
    fastcgi_no_cache $skip_cache;
    # ... other fastcgi settings
}

$skip_cache should trip for logged-in users, POST requests, and any admin path (wp-admin, wp-login.php, xmlrpc.php). Get this wrong and different users see each other's carts.

A high-traffic news site went from 1.2s server response time to 180ms after this configuration landed.

5. Hosting mismatch

Running a WordPress site with real traffic on $5/month shared hosting is optimizing the wrong side of the equation. You'll spend weeks tuning the site while the underlying constraint is a shared kernel with 400 other tenants competing for CPU.

Red flags on a hosting audit:

• Shared hosting for sites with 10,000+ monthly visitors
• No SSD storage (yes, this still happens)
• PHP version older than 8.1
• No option for server-level caching
• Memory limit at 128MB or lower

Rough sizing guide by monthly traffic:

Visitors/month	Right tier	Cost range
0-5K	Quality shared hosting	$10-20/mo
5K-50K	Properly configured VPS	$20-50/mo
50K+	Managed WordPress or custom VPS	$50+/mo

Moving one client from $8/month shared to a $25/month VPS took their site from 4.5s to 1.8s. Same code, same content, different machine.

Where to start

If you're only going to fix one thing today, do the database cleanup. An afternoon of work, immediate visible impact, no product tradeoffs. If you're fixing two, right-size the hosting. Those two together cover most of the wins on a neglected WordPress site.

The other three (images, plugins, caching) touch product decisions. Which images belong on the homepage. Which plugins the team actually depends on. Which cache invalidation strategy fits the editorial workflow. Those conversations belong with the site owners, not the DevOps engineer running the audit.

• Plugin optimization: 15-40% speed improvement
• Proper caching: 30-70% speed improvement
• Hosting upgrade: 25-60% speed improvement

Combined effect: Most sites see 40-70% overall improvement when all issues are addressed properly.

Common Mistakes to Avoid

1. Over-optimization: Don't chase perfect scores, chase good user experience
2. Plugin addiction: More caching plugins doesn't mean better performance
3. Ignoring mobile: 60%+ of traffic is mobile, optimize for it first
4. One-time fixes: Performance optimization needs ongoing maintenance
5. Cheap shortcuts: Free solutions often cost more in the long run

Your Next Steps

If your WordPress site is slow, start with these priorities:

1. Run a performance audit - Get baseline numbers first
2. Clean your database - Often the biggest quick win
3. Optimize images - Especially if you have a visual site
4. Audit plugins - Remove what you don't actually need
5. Set up proper caching - This can transform your site

Performance optimization isn't just about technical tweaks - it's about creating better user experiences that convert visitors into customers.

---