Why Is My WordPress Site Slow? The 7 Most Common Causes (and How to Fix Them)

Speed matters more than most site owners realize. Research by Portent found that e-commerce sites loading in one second had a conversion rate of 3.05% — sites taking five seconds to load converted at just 1.08%. For lead generation sites, Portent found a 1-second load correlated with a 39% conversion rate, dropping to 18% at six seconds. And Google's own Core Web Vitals documentation states that performance "aligns with what our core ranking systems seek to reward."

Before you can fix a slow WordPress site, you need to know what is actually slow. Guessing wastes time and money. This guide starts with measurement, then works through the seven most common causes in the order most likely to apply to a typical WordPress site.

Step 1: Measure Before You Touch Anything

Run your site through Google PageSpeed Insights before changing anything. It gives you scores for mobile and desktop, and more importantly, it names the specific metrics that are failing. The three Core Web Vitals you are being measured against are:

Metric	What It Measures	Good	Needs Improvement	Poor
LCP — Largest Contentful Paint	How long the largest visible element takes to load	≤ 2.5s	2.5s – 4.0s	> 4.0s
INP — Interaction to Next Paint	How quickly the page responds to a user action	≤ 200ms	200ms – 500ms	> 500ms
CLS — Cumulative Layout Shift	How much visible content unexpectedly shifts during load	≤ 0.1	0.1 – 0.25	> 0.25

Thresholds are sourced directly from web.dev/vitals, maintained by the Google Chrome team. Google assesses a site's performance against these metrics at the 75th percentile of all page loads — meaning your site needs to hit the Good threshold for at least 75% of visitors, not just on a clean test run.

Note the specific failing metrics before moving on. LCP failures usually point to hosting speed or image issues. CLS failures usually point to fonts, ads, or images without defined dimensions. INP failures usually point to JavaScript execution. Each cause section below maps to the metric it most commonly affects.

Also check your Time to First Byte (TTFB) in the PageSpeed Insights "Diagnostics" section. TTFB measures how long the server takes to start responding. A TTFB above 600ms before a single byte arrives at the browser is almost always a hosting or caching problem, not a code problem.

Cause 1: Shared Hosting With No Server-Side Caching

Most likely culprit if: your TTFB is over 600ms and you are on a budget shared hosting plan.

WordPress is a dynamic platform. Every time someone visits a page, the server executes PHP code and queries the MySQL database to assemble the HTML response. On a well-configured server, this takes 50–150ms. On a busy shared server with no caching, it can take 600ms to several seconds — before the browser has received a single byte.

Server-side page caching stores the assembled HTML output so that repeat visits to the same page are served from memory rather than re-executing PHP and MySQL. The difference between a cached response and an uncached one is often the entire difference between a fast site and a slow one.

How to check: Install the free Query Monitor plugin and load a page. It will show you the number of database queries executed per page load and their total time. A typical well-optimized WordPress page runs 30–60 queries. Over 100 queries per page, or queries totalling more than 200ms, is a red flag. If the server is also not caching, every visitor triggers those queries.

Fix: If you are on shared hosting, install a page caching plugin. W3 Total Cache and WP Super Cache are free and widely used. Configure page caching and enable browser caching. This will significantly reduce TTFB for cached pages.

If your TTFB remains high after enabling a caching plugin, the server itself is the constraint — either the hardware is undersized for the load, or you are on a plan with such aggressive resource throttling that even cached responses are slow. At that point, the fix is a better hosting plan rather than a plugin.

Cause 2: Unoptimized Images

Most likely culprit if: your LCP score is poor and the failing element is an image.

Images are the most common cause of slow Largest Contentful Paint. The three most common image problems on WordPress sites:

Images not compressed: A photograph uploaded directly from a camera can be 5–15MB. The same image displayed at 800px wide on a website needs to be under 200KB to avoid being a performance liability.
Wrong format: JPEG is fine for photographs. PNG is appropriate for images with transparency. WebP is a newer format that typically achieves 25–35% smaller file sizes than JPEG at equivalent quality and is supported by all modern browsers.
Missing dimensions: If an image's width and height are not specified in the HTML or CSS, the browser cannot reserve space for it while loading. When it finally loads, the surrounding content shifts — causing CLS failures.
Not lazy-loaded: Images below the fold (not visible until the user scrolls) should be lazy-loaded so they do not block the initial page render. WordPress has had native lazy loading since version 5.5.

Fix: Install ShortPixel or Imagify (both have free tiers) to compress and convert existing images to WebP. Both plugins process images in bulk and handle future uploads automatically. Always define width and height attributes on images — WordPress adds these automatically when you insert images through the media library, but custom themes and page builders sometimes strip them.

Cause 3: Too Many Plugins, or One Poorly Written One

Most likely culprit if: your INP is poor, or PageSpeed flags "Reduce JavaScript execution time" or "Avoid chaining critical requests."

Plugin count alone is not the problem — a site with 30 well-written plugins can outperform one with 8 bad ones. The issue is plugins that load large JavaScript libraries on every page, execute slow database queries, or make external HTTP requests on page load.

How to identify the offending plugin: Use the Query Monitor plugin to see which plugins are adding the most database queries and which are taking the most time. Then deactivate suspected plugins one at a time and re-test with PageSpeed Insights after each deactivation. When the score improves noticeably, you have found the culprit.

Common plugin performance offenders:

Visual page builders that load their full CSS and JavaScript framework on every page, even pages that do not use them
Social sharing plugins that load external SDK scripts from Facebook, Twitter/X, or Pinterest on page load
Slider and gallery plugins with large JavaScript dependencies
Live chat plugins that load third-party scripts synchronously
Poorly written custom plugins that run expensive queries on every page load

Fix: Replace or remove the slow plugin, or configure it to load its assets only on the pages where it is actually used. Most reputable plugins offer asset loading controls in their settings.

Cause 4: No Content Delivery Network (CDN)

Most likely culprit if: your server is in one geographic region but you have visitors from across the country or internationally.

A CDN stores copies of your site's static assets (images, CSS, JavaScript) on servers distributed geographically. When a visitor in Dallas requests an image from a site hosted in New Jersey, that request travels across the country and back. With a CDN, a Dallas visitor receives the image from a CDN node in Dallas — dramatically shorter round-trip time.

CDN impact is most significant for static assets and least significant for the dynamic HTML that WordPress generates. For a US-only audience, a CDN's effect on perceived page speed is real but not transformational if your server is already on the same coast as most of your traffic. For international visitors, it can be substantial.

Fix: Cloudflare offers a free CDN tier that is straightforward to enable — you point your domain's nameservers to Cloudflare, and it proxies and caches your traffic automatically. Many managed WordPress hosting plans include CDN as part of the plan. If yours does, confirm it is enabled.

Cause 5: A Slow or Bloated WordPress Theme

Most likely culprit if: the site was recently redesigned using a new theme or page builder and performance dropped.

Themes vary enormously in performance. Lightweight themes like GeneratePress and Astra are engineered for speed — they load minimal CSS and JavaScript and defer rendering-blocking assets. Heavy multipurpose themes like Divi and Avada are full-featured but ship with large CSS and JavaScript bundles that can add several hundred kilobytes to every page load.

Page builders (Elementor, Divi Builder, WPBakery) are particularly prone to loading their full asset stack on every page, including pages that were built with a different tool or in plain HTML. This is a known trade-off of builder-based sites.

How to check: In PageSpeed Insights, expand "Reduce unused CSS" and "Reduce unused JavaScript." If the savings shown are very large (over 500KB), your theme or page builder is the likely source.

Fix: If switching themes is not practical, install a plugin like Asset CleanUp to disable unused CSS and JavaScript on specific page types. If the theme is the root issue and the site is due for a redesign, rebuilding on a lightweight theme will produce more durable performance gains than any plugin workaround.

Cause 6: WordPress Database Bloat

Most likely culprit if: the site has been running for several years and was never optimized.

WordPress stores everything in its database: posts, pages, settings, plugin data, revisions, transients, and spam comments. Over time, tables accumulate data that is no longer needed but still makes every query slightly slower.

Common sources of database bloat:

Post revisions: WordPress saves a revision every time you update a post. A post edited 50 times has 50 revision entries. By default there is no limit on revisions.
Orphaned plugin data: When a plugin is deleted, its database tables and option rows often remain. Reinstalling and properly uninstalling plugins, or using a cleanup tool, removes these.
Expired transients: WordPress uses transients (temporary cached database values) extensively. Expired transients that were never cleared accumulate in the wp_options table.
Spam and trashed comments: Comments in the spam or trash queue remain in the database until manually deleted or automatically purged.

Fix: WP-Optimize is a free plugin that handles database cleanup — removing revisions, clearing transients, optimizing tables, and deleting spam comments — without requiring direct database access. Run it once and schedule it to run monthly. To limit future revision accumulation, add define('WP_POST_REVISIONS', 5); to your wp-config.php file to cap revisions at five per post.

Cause 7: No Object Cache

Most likely culprit if: page caching is enabled but dynamic pages (cart, checkout, logged-in views) are still slow.

Page caching stores complete HTML output and is highly effective for static content viewed by logged-out visitors. It cannot cache personalized content — a WooCommerce cart page, a member dashboard, or any page that differs by user. For these pages, an object cache makes the underlying database queries faster without bypassing them entirely.

Object caching (Redis or Memcached) stores the results of database queries in memory. The next time the same query is needed, WordPress reads from the in-memory cache rather than executing a database query. For sites with heavy dynamic content, this can reduce database load significantly and improve response times on pages that cannot be page-cached.

How to check if you have it: Object caching is a server-level feature — it must be available on your hosting plan and then enabled in WordPress. Check your hosting control panel for Redis or Memcached options. If neither is available, your hosting plan does not support object caching.

Fix: If your host supports Redis, install the Redis Object Cache plugin and follow its setup instructions. If your host does not offer Redis or Memcached, this optimization is not available to you without changing hosts.

Putting It Together: The Diagnostic Order

Work through these in order — the earlier causes are both more common and easier to address:

Run PageSpeed Insights. Note your TTFB, LCP, INP, and CLS scores.
If TTFB is over 600ms: check server-side caching first. Add a caching plugin or upgrade hosting.
If LCP is poor and the LCP element is an image: compress and convert images to WebP.
If INP is poor or JavaScript bloat is flagged: audit plugins, deactivate one at a time to find the offender.
If the site has international visitors and no CDN: enable Cloudflare or your host's CDN.
If the theme or page builder is loading hundreds of kilobytes of unused assets: use Asset CleanUp or rebuild on a lighter theme.
If the site is several years old and has never been optimized: run WP-Optimize and limit post revisions.
If you have WooCommerce or logged-in user pages that are still slow after page caching: confirm whether your host supports Redis and enable it.

When the Problem Is the Hosting Plan

Plugin fixes and image compression can only improve performance within the constraints of your hosting environment. If your server has a slow CPU, limited RAM, or no caching layer available, there is a ceiling on how fast your WordPress site can get without changing hosts.

The signs that hosting is the constraint rather than the site's code:

TTFB over 800ms even with caching enabled
Performance varies dramatically by time of day (a sign of shared-server resource contention)
Performance dropped shortly after the hosting plan renewed at a higher tier — a sign the host may have moved you to a more loaded server
Your host does not offer Redis, Memcached, or server-side page caching

Vortex Media's managed WordPress hosting plans are configured with FastCGI page caching and Redis object caching out of the box. If you are hitting a hosting-side performance ceiling, book a free call — we will run a performance audit of your current site before recommending anything.