Why Your WordPress Site Is Slow - and It's Not Just the Hosting

The first thing most people do when their WordPress site is slow is blame the hosting. Sometimes they're right — genuinely bad hosting does exist and it does make a real difference. But in most cases the hosting is fine and the site is slow for half a dozen other reasons that have nothing to do with the server.

Performance is not one problem with one fix. It's a stack of small decisions that compound. Get enough of them right and the numbers move significantly. Miss enough of them and no hosting upgrade will save you.

Hosting actually does matter — but not how you think

Let's address the hosting question properly. Yes, hosting makes a difference — and more than people admit.

A cheap shared hosting plan where your site shares resources with hundreds of other sites doesn't just make your site slower. It throttles you. CPU limits, memory limits, connection limits — when any of those are hit your site grinds to a halt regardless of how well optimised everything else is. A traffic spike that a decent server would handle without blinking can bring a shared hosting site down entirely. No amount of caching or image optimisation fixes a server that's being deliberately restricted.

The irony is that super cheap hosting often ends up being expensive. Slow sites lose visitors, lose conversions, lose search ranking. The $3/month saving costs more than it saves.

For client sites I recommend SiteGround. It's not the cheapest option but the performance is consistent, the infrastructure is solid, and they have their own caching solution that works extremely well out of the box. Clients don't call me six months later with mysterious slowdowns.

For developers who want full control — and are comfortable managing a server — a VPS from Hetzner with Coolify is hard to beat. You configure everything yourself: PHP settings, caching, server resources, the works. No arbitrary limits, no resource throttling, and the cost is a fraction of managed hosting at the same performance level. The trade-off is that you own the maintenance.

Hosting is the foundation. Everything else builds on top of it. Get the foundation wrong and the ceiling is low no matter what you do above it.

Caching is the single biggest lever

If there's one change that has the most dramatic impact on WordPress performance it's proper caching. A WordPress page without caching is dynamically generated on every request — PHP executes, database queries run, HTML is assembled and sent. With caching, the first request generates the page and every subsequent request gets a static file. The difference in response time is significant.

I use LiteSpeed Cache on every project. It's free, it's deeply integrated with LiteSpeed servers (which SiteGround uses), and the results are consistently good. The page cache alone moves the needle substantially. Combined with browser caching, object caching, and database query caching the difference is dramatic.

The plugin also handles CSS and JavaScript minification and combination, lazy loading, and image optimization — which means one well-configured plugin handles most of the performance checklist.

The key word is configured. Caching plugins installed with default settings help but don't deliver their full potential. Spend time in the settings — enable the page cache, configure browser cache headers, enable CSS and JS minification, set up object cache if the host supports it. The defaults are conservative. Push them.

Images are the most common culprit

Unoptimized images are the most common reason WordPress sites fail performance audits. A full-size JPEG exported from Photoshop at 3000px wide has no business being served to a mobile device. Yet it happens on almost every site that hasn't been deliberately optimized.

The fix has two parts: format and size.

For format I convert everything to WebP. WebP is significantly smaller than JPEG or PNG at comparable quality — typically 25-35% smaller. I use EWWW Image Optimizer for bulk conversion of existing images and automatic conversion of new uploads. The difference in page weight is immediately visible in the performance scores.

For size I make sure images are sized appropriately for their context. A card thumbnail doesn't need to be 1200px wide. A hero image doesn't need to be 4000px wide. WordPress generates multiple sizes automatically — the key is using the right size in the right place, which means checking that themes and plugins are using srcset and serving appropriately sized images per device.

Lazy loading is also essential. Images below the fold shouldn't block the initial page load. WordPress has native lazy loading built in but it's worth verifying it's actually applied, especially on images added through page builders.

Unused CSS and JavaScript

Most WordPress sites load far more CSS and JavaScript than any given page actually uses. A theme ships with styles for every possible component. Plugins enqueue scripts globally even on pages where they're not needed. It adds up.

On custom builds I strip unused CSS aggressively. If a client doesn't use a section I remove the styles for it entirely — not commented out, deleted. For third-party components I scope their styles to only the pages or post types where they're actually used using conditional enqueuing:

add_action( 'wp_enqueue_scripts', 'project_enqueue_scripts' );

function project_enqueue_scripts() {
  if ( is_woocommerce() || is_cart() || is_checkout() ) {
    wp_enqueue_style( 'woocommerce-styles' );
  }
}

This keeps the page weight lean on pages that don't need those styles. The same principle applies to JavaScript — enqueue it only where it's needed, not globally.

Minification handles the rest. Minified CSS and JS files are smaller and load faster. LiteSpeed Cache handles this automatically once configured.

WooCommerce needs special attention

WooCommerce is powerful but it comes with a performance cost. It runs a significant number of database queries on every page load — product queries, cart queries, session queries, inventory checks. On a large store with many products and variations this adds up quickly.

The WooCommerce team is actively working on query optimization and each major release improves things, but it remains one of the heavier WordPress plugins by default.

A few things that help on WooCommerce sites specifically: enable object caching (Redis or Memcached if the host supports it), use a dedicated WooCommerce caching configuration in LiteSpeed Cache rather than the default page cache settings, and keep the product catalog well-organized with proper indexing. Query Monitor is useful here — it shows exactly which queries are running, how long they take, and which plugin or theme triggered them. Slow queries stand out immediately.

WooCommerce is also a good argument for good hosting. The query load means the server needs to be able to handle it — shared hosting with resource limits struggles with busy WooCommerce stores in ways that a VPS or quality managed hosting doesn't.

CDN makes everything faster globally

A CDN — Content Delivery Network — serves your static assets from servers geographically close to the visitor. Images, CSS, JavaScript, and cached pages load from a nearby node instead of your origin server. For visitors far from your server location the difference is significant.

Cloudflare is the obvious choice — free tier, easy setup, reliable. You point your domain's nameservers to Cloudflare and it sits in front of your site handling caching, CDN, and DDoS protection automatically. Combined with LiteSpeed Cache on the origin server the setup is extremely fast.

For international audiences or sites with global traffic a CDN isn't optional — it's the difference between a fast site and a frustrating one.

Using the data — Query Monitor and PageSpeed

Optimizing without measuring is guessing. I use two tools on every performance audit:

Google PageSpeed Insights gives a score out of 100 and specific actionable recommendations — what's slow, what's causing layout shifts, what's blocking render. I aim for green across the board on both mobile and desktop. Mobile is harder and more important — Google uses mobile performance for search ranking.

Query Monitor shows what's happening on the server side — database queries, hooks, HTTP requests, PHP errors. It's invaluable for identifying slow queries, duplicate queries, and plugin conflicts that don't show up in frontend performance tools. On WooCommerce sites in particular it regularly reveals queries that shouldn't be running on every page load.

Between these two tools most performance problems are diagnosable within minutes.

It all adds up

No single fix makes a slow site fast. Good hosting gives you capacity. Caching eliminates redundant work. WebP images reduce page weight. Unused CSS removal keeps payloads lean. A CDN reduces latency globally. Query optimization keeps the server responsive under load.

Each improvement is incremental. Combined they compound into a site that scores well, loads fast, and stays fast as traffic grows. The sites that perform consistently well are the ones where each of these decisions was made deliberately — not as a last-minute audit before launch, but as a standard part of how the site was built.

Performance is not a feature you add. It's the result of not cutting corners on a dozen small things.