Here is why WordPress sites slow down: nothing breaks all at once. Plugins pile up, the database fills with records nobody deletes, images get uploaded at full camera resolution, the PHP version falls behind, and the caching that was set up at launch quietly stops working. Your site was fast on day one and sluggish two years later because every one of those things moved in the wrong direction a little at a time.
That matters for how you fix it. A single plugin install will not undo two years of accumulation. You have to find out which causes are actually active on your site, then work through them in the order that gives you the biggest return for the least risk.
Slowdown is accumulation, not a single failure
A new WordPress install with a default theme and no plugins is fast. Everything you add after that costs something: another database query, another stylesheet, another script, another external request. Individually, none of it is noticeable. Together, it is the difference between a page that paints in under two seconds and one that takes six.
The second half of the problem is that a site is not static even when you stop touching it. WordPress writes post revisions every time you save. Plugins write their own tables and log rows. Expired transients sit in the options table. Spam comments accumulate. The site gets heavier while you do nothing at all.
The seven usual causes
Nearly every slow WordPress site we look at is explained by some combination of these. Work down the list and mark which ones apply to you.
- Plugin creep. Not the count, the weight. Thirty lightweight plugins can outperform eight that each load their own jQuery bundle on every page. Watch especially for sliders, page builder add-ons, related-post engines, social feed widgets and anything that calls an outside service on page load.
- Database bloat. Post revisions, auto-drafts, expired transients, orphaned postmeta from plugins you removed, spam comments, and plugin log tables. An options table full of autoloaded rows is one of the most common hidden causes of slow admin screens and slow first bytes.
- Unoptimized images. A 4,000-pixel photo straight off a phone, served at 600 pixels wide, wastes most of its bytes. Multiply that across a page of eight images and the page weight problem solves itself once you address it.
- An outdated PHP version. Each modern PHP release handles WordPress work faster than the one before. Sites left on an old version are leaving measurable speed on the table and losing security updates at the same time.
- Theme and builder overhead. Heavy themes and visual builders generate deeply nested markup and load their full asset library on pages that use none of it. This is fixable without rebuilding the site, but it needs a deliberate pass.
- Caching that broke or was never finished. Caching plugins get installed, then conflict with a membership or cart plugin, so someone disables page caching “temporarily” and nobody turns it back on. Object caching is often never configured at all.
- Hosting you have outgrown. Cheap shared plans put you on a server with hundreds of other sites. When their traffic spikes, your time to first byte does too. No amount of front-end optimization fixes a server that is already busy.
How to find out which cause is yours
Do not start fixing. Start measuring, or you will have no idea which change helped.
Measure before you touch anything
Run your three most important pages (home, your main service page, and one blog post) through a page speed tool and save the results. Note the load time, the page weight in megabytes, the number of requests, and the time to first byte. Those four numbers are your baseline.
Separate server time from front-end time
Time to first byte tells you how long the server took to produce the HTML. If that number is high, your problem is server side: hosting, PHP version, database, or an uncached query. If time to first byte is fine but the page still takes forever to look finished, your problem is front end: images, scripts, fonts, render-blocking CSS.
This single distinction saves most people from optimizing the wrong half of their site.
Test on a copy, never on the live site
Clone the site to a staging environment. Deactivate plugins in groups, retest after each group, and you will find the expensive ones quickly. Doing this on a live site risks taking your homepage down in front of customers.
How to fix a slow WordPress site, in order
This sequence is deliberate. Each step either reduces work for the next one or makes its effect easier to see.
- Take a full backup you have actually restored once. Files and database. Before anything else.
- Update PHP to a current supported version. Test on staging first, because very old plugins occasionally break. This is often the single largest server-side win available.
- Clean the database. Delete post revisions beyond a reasonable limit, clear expired transients, remove orphaned metadata, and check for autoloaded options that have grown large. Then set a revision limit so it does not come back.
- Fix images. Compress what is already in the media library, convert to a modern format like WebP, serve correctly sized versions, and turn on lazy loading for anything below the fold.
- Configure caching properly. Page caching at minimum. Object caching if your host supports it. Browser caching headers for static assets. Verify it is actually serving cached pages rather than just being installed.
- Put a CDN in front of static assets. Images, CSS, JavaScript and fonts served from edge locations close to the visitor instead of one origin server.
- Remove or replace heavy plugins. Only now, with measurements in hand, so you know which ones to argue with.
- Re-measure the same three pages. Compare against your baseline. Keep the record.
What keeps it fast afterward
The fix is the easy part. Sites slide back within months without a cadence. This is the minimum that holds the line:
| Task | How often | Why it matters |
|---|---|---|
| Plugin, theme and core updates | Weekly, on staging first | Closes security holes and performance regressions |
| Database cleanup | Monthly | Stops revision and transient buildup |
| Image audit on new uploads | Monthly | Prevents page weight creeping back up |
| Speed check on key pages | Monthly | Catches regressions while they are small |
| PHP version check | Quarterly | Keeps you on a supported, faster runtime |
| Backup restore test | Quarterly | Proves the backups actually work |
| Full performance review | Twice a year | Finds the slow accumulation you stopped noticing |
Nothing on that list is difficult. The difficulty is that it is boring, it never produces a visible result on a good week, and it is the first thing to fall off a busy owner’s calendar.
When it is not worth doing yourself
Some of this is genuinely a one-afternoon job. Compressing images and setting a revision limit, for example. Other parts are not: PHP upgrades that need plugin compatibility testing, caching that has to coexist with a cart or membership system, and deciding whether a theme can be slimmed down or needs replacing.
The honest test is whether you will keep doing the monthly work. A one-time cleanup buys you six good months. A cadence keeps the site fast permanently. If the cadence is not going to happen, the cleanup is a temporary purchase.
Start by finding out where you actually stand. Run the measurements described above on your three most important pages, write the numbers down, and work the fix list in order. If you would rather have someone else do that pass and hand you the before-and-after numbers, request a review on the Free Website Audit page.