Slow websites lose visitors, and the usual advice — “install a caching plugin” — treats one symptom of a problem that usually has four or five causes. This guide walks through what actually makes a WordPress site slow, in the order that produces the biggest improvement first, with the reasoning behind each step.
Measure before you change anything
Optimising without measurement means you cannot tell whether a change helped, and you will keep plugins you did not need.
Run your site through a speed testing tool and note three numbers specifically. Largest Contentful Paint measures how long the main content takes to appear. Cumulative Layout Shift measures how much the page jumps around while loading. Interaction to Next Paint measures responsiveness to clicks and taps. These are the metrics Google uses for its page experience signals, and they map closely to what users actually perceive.
Test the same page three times and take the median. Single runs vary enough to mislead you. Test a post and a page, not just the homepage, since they often have different plugin loads.
Also open your browser’s Network tab, sort by size, and look at the largest requests. This one habit identifies the real bottleneck on most sites within thirty seconds.
Step 1: Hosting, because everything else sits on top of it
Time to First Byte — how long the server takes to begin responding — is set almost entirely by your host. If that number is above roughly 600 milliseconds, no amount of image compression will rescue the page.
Cheap shared hosting puts hundreds of sites on one machine competing for the same CPU and disk. Everything you do afterwards is fighting that constraint. Moving to a better host is unglamorous and frequently the single largest improvement available.
Check three things with your current host: the PHP version (8.x is substantially faster than 7.x and older versions no longer receive security updates), whether object caching is available, and whether the server is geographically near your audience.
Step 2: Page caching
By default, WordPress builds every page on every request — running PHP, querying the database, assembling the template. Page caching stores the finished HTML and serves it directly, skipping all of that.
The improvement is usually dramatic, often cutting server response time by eighty percent or more. Many quality hosts provide caching at the server level, which is faster than any plugin can be and should be used in preference to one. If yours does not, a single caching plugin will do it.
The important discipline: use one caching plugin. Two of them fighting over the same files produces inconsistent pages and strange bugs that are difficult to diagnose.
Remember that logged-in users and dynamic pages — cart, checkout, account — must be excluded from the cache, or people will see each other’s data. Reputable plugins handle this by default; verify it rather than assuming.
Step 3: Images, usually the largest single win
Images are typically the heaviest part of a page by a wide margin. Three separate problems are worth fixing.
Dimensions. Uploading a 4000px-wide photograph to display at 800px means the browser downloads roughly twenty-five times more data than it needs. Resize before uploading.
Format. WebP typically produces files around thirty percent smaller than JPEG at equivalent quality, and AVIF smaller still. WordPress supports WebP natively, and conversion plugins can handle existing media libraries.
Loading strategy. Images below the fold should not load until the user scrolls near them. WordPress adds loading="lazy" automatically to most images now. Crucially, you should exclude the main hero image from lazy loading — deferring the largest visible element makes your Largest Contentful Paint worse, which is the opposite of the intent.
Always specify width and height attributes. Without them the browser cannot reserve space, and the page shifts as each image arrives, which is exactly what Cumulative Layout Shift penalises.
Step 4: Audit your plugins honestly
Plugin count matters less than plugin behaviour, but both matter. A single badly-written plugin that loads its assets on every page and runs uncached queries on every request can outweigh twenty well-behaved ones.
Work through the list and ask of each: does this earn its place? Deactivate anything unused, then delete it — deactivated plugins still occupy disk space and remain a security surface.
Watch for particular categories. Page builders add substantial CSS and JavaScript. Social sharing plugins often load external scripts from several domains. Statistics and related-posts plugins that query the database on every page view are a common hidden cost. Sliders are frequently the heaviest element on a homepage while delivering little measurable benefit.
Many optimisation plugins can restrict a plugin’s assets to the pages that actually use it. A contact form’s scripts do not need to load on every blog post.
Step 5: CSS and JavaScript delivery
Render-blocking resources sit between the browser and displaying anything. Three techniques help.
Minification strips whitespace and comments. Small gains, essentially free.
Deferring JavaScript lets the HTML parse without waiting. Most scripts do not need to run before content appears.
Removing unused CSS can be substantial, since themes often ship styles for features your site does not use.
A caution: these are the settings most likely to break a site. Enable them one at a time, clear the cache, and check the homepage, a post, and a form on both desktop and mobile after each change. If something breaks, you know exactly which setting caused it.
File combining was standard advice under HTTP/1.1. With HTTP/2, which multiplexes many requests over one connection, combining is often neutral or harmful. Check whether your host serves HTTP/2 before enabling it.
Step 6: The database
WordPress accumulates data indefinitely: post revisions, auto-drafts, trashed items, expired transients, spam comments, and orphaned metadata from plugins you removed months ago.
Clean it periodically, and take a backup first — cleanup operations are destructive by nature.
You can also limit revisions going forward by adding a line to wp-config.php:
define('WP_POST_REVISIONS', 5);This keeps the five most recent revisions per post instead of an unbounded history. On a site with hundreds of posts edited repeatedly, the difference in database size is significant.
Step 7: A content delivery network
A CDN serves your static files from servers distributed worldwide, so a visitor in another continent downloads images and stylesheets from a nearby location rather than your origin server.
The benefit is proportional to how geographically spread your audience is. For a local business serving one city, it matters little. For anything international, it is one of the more meaningful remaining improvements. Most CDNs also absorb traffic spikes and provide a layer of protection against denial-of-service attempts.
Step 8: Fonts
Web fonts are a quiet performance cost. Each weight and style is a separate file, and text is often invisible while they load.
Limit yourself to two families and only the weights you genuinely use — loading nine weights of a font when the design uses two is common and entirely wasteful. Host fonts locally rather than fetching them from a third party, which removes an external DNS lookup and connection. Add font-display: swap so text renders immediately in a fallback font and swaps when the web font arrives.
What to skip
A few popular ideas deliver little.
Chasing a perfect score. Testing tools report a score and a set of real-world metrics. The metrics are what matter. A site can score in the seventies and feel instant, or score highly and feel sluggish on a mid-range phone.
Stacking optimisation plugins. Three plugins each minifying CSS do not produce three times the benefit. They produce conflicts.
Aggressive settings you do not understand. If enabling something breaks the layout and you cannot explain what it did, turn it off. A slightly slower working site beats a fast broken one.
Frequently asked questions
How many plugins is too many?
There is no threshold number. Twenty lightweight, well-maintained plugins can outperform five heavy ones. Judge by measured impact, not by count.
Does my theme affect speed?
Considerably. Multipurpose themes bundled with sliders, portfolio systems and demo importers carry that weight on every page load whether you use the features or not. A lean theme is easier to make fast than a heavy one is to slim down.
Why is my site fast for me and slow for visitors?
Your browser has cached everything, and you may be geographically close to the server. Test in a private window, from a different network, and with mobile throttling enabled to see what a first-time visitor experiences.
Should I test on mobile or desktop?
Both, but prioritise mobile. It is where most traffic comes from and where slow sites hurt most, because mobile devices have less processing power and more variable connections.
Conclusion
Work in order of impact: a capable host, page caching, properly sized and modern-format images, an honest plugin audit, careful asset delivery, a clean database, and a CDN if your audience is spread out. Measure before and after each change, alter one thing at a time, and judge by real metrics rather than a score. That sequence handles the great majority of WordPress performance problems without guesswork.
