Why Your WordPress Site Gets Slower Every Year (And the Six Fixes That Actually Work)

Two years ago your site loaded in 1.4 seconds. Nobody has done anything dramatic to it since. It now takes 5.8 seconds on a phone, your Google Search Console says “Poor” on mobile, and your contact form submissions are down.

Nothing broke. The site got slow the way people get out of shape: gradually, through a long series of individually reasonable decisions.

I spent two and a half years maintaining a portfolio of more than 150 WordPress sites for a US agency, and the decay pattern is almost identical every time. Here is what actually happens, and what to do about it in the order that gives you the most back for the least money.

How a fast site becomes a slow one

1. Plugins accumulate, and nothing is ever removed

Someone needed a contact form. Then a slider. Then a popup, an SEO plugin, a security plugin, a caching plugin, a social sharing plugin, a related posts plugin and an analytics plugin because the first one was confusing.

Here is the part most business owners miss: most plugins load their CSS and JavaScript on every page of your site, whether that page uses the feature or not. A popup plugin you use on two landing pages is loading on your blog. A slider plugin is loading on your contact page. Thirty plugins can easily mean forty extra HTTP requests and 800KB of assets on a page that needs none of it.

2. Images are uploaded straight from a phone or a stock site

A modern phone photo is 4000 pixels wide and four megabytes. Someone on your team uploads it into a slot that displays at 600 pixels. WordPress generates smaller versions, but if the theme or builder asks for the full size — and many do — the browser downloads all four megabytes to show a thumbnail.

Multiply that by a few dozen pages of content added over two years and you have the single most common cause of a slow WordPress site.

3. The database quietly fills with sludge

Post revisions (WordPress keeps every single one by default), expired transients, orphaned metadata from plugins you deleted, spam comments, and in WooCommerce’s case a scheduled-actions table that can reach hundreds of thousands of rows.

None of this is visible from the front end. All of it makes every query slower.

4. The theme or builder was never the fast one

Multipurpose themes sold on marketplaces are built to demo well, which means they ship with sliders, icon fonts, animation libraries, three different grid systems and a page builder bundled in. Page builders themselves add deeply nested markup — a simple two-column section can become eleven nested divs with inline styles.

5. Hosting was chosen on price three years ago

Shared hosting at $4/month puts you on a server with hundreds of other sites. When one of them gets busy, yours slows down. You cannot optimise your way out of insufficient PHP workers.

6. Third-party scripts got added and never audited

Google Analytics, Tag Manager, a Facebook pixel, a live chat widget, a review widget, a booking embed, a heatmap tool someone trialled in 2024 and forgot to remove. Each one is a request to someone else’s server, and your page is often waiting for it.

The six fixes, in the order worth doing them

Fix 1 — Sort out your images (biggest win, lowest cost)

This is almost always the single largest improvement available, and it is cheap.

• Convert everything to WebP. It is typically 25–35% smaller than JPEG at the same visual quality, and every browser in current use supports it.
• Resize to the largest size they are ever actually displayed at. A full-width hero rarely needs more than 1920px. A blog thumbnail needs 600.
• Lazy-load everything below the fold — but not your hero image, which is almost always your Largest Contentful Paint element. Lazy-loading your LCP image makes the score worse.
• Always set explicit width and height attributes. This is what stops the page jumping around as images load, which is your Cumulative Layout Shift score.

Fix 2 — Audit the plugins, honestly

Go through the list and put each plugin in one of three buckets: actively used, replaceable with a few lines of code, or not used at all.

The third bucket is usually bigger than people expect. The second bucket is where the real savings are — a 1.8MB “social sharing” plugin replaced by twenty lines of HTML, or a slider plugin replaced by CSS scroll-snap.

Deactivating is not enough, by the way. Delete what you are not using. Deactivated plugins still sit in your filesystem as a security surface.

Fix 3 — Stop loading assets where they are not needed

This is the fix that separates a developer from a plugin. You can conditionally dequeue scripts and styles so a plugin only loads on the pages that use it. On a typical WooCommerce site, keeping the cart fragments script and block styles off non-shop pages is a measurable improvement on its own.

It takes maybe an hour of work and it is permanent.

Fix 4 — Clean the database, then keep it clean

• Limit post revisions to 5 rather than infinite.
• Clear expired transients and orphaned metadata.
• On WooCommerce, prune completed scheduled actions and old order logs.
• Optimise tables afterwards.

Take a backup before any of this. Then schedule it so it happens quarterly instead of once, dramatically, in year three.

Fix 5 — Cache properly, at the right layers

Page caching, object caching, browser caching and a CDN do different jobs. Most sites have one of them configured badly and call it done.

The common failure is caching too aggressively on dynamic pages — cart, checkout, account areas, anything personalised. A cached cart page that shows one customer’s basket to another is a worse problem than a slow site.

Fix 6 — Fix hosting last, when you have proven it is the bottleneck

If the server’s time-to-first-byte is 900ms before a single asset downloads, no amount of front-end work saves you. Managed WordPress hosting in the $25–50/month range is a different category of machine from $4 shared hosting, and for a site that generates revenue it is not an extravagance.

But check this last. Moving hosts is disruptive, and most “slow hosting” complaints turn out to be a 4MB hero image.

What a realistic result looks like

On a typical neglected small-business WordPress site, images and plugin cleanup alone usually take a page from the four-to-six second range down to around two. Conditional asset loading and caching get you under two. Hosting closes the last gap if it is still there.

You will not get a 100 Lighthouse score, and you should be suspicious of anyone who promises one. What you want is a site that feels instant on a phone on a mediocre connection, and Core Web Vitals in the green for real visitors.

The maintenance habit that prevents all of this

Everything above is remedial. The way you avoid needing it again:

• Resize and compress images before upload. Train whoever adds content.
• Review the plugin list every quarter and delete what is not earning its place.
• Before installing anything new, ask what it loads and where.
• Re-run a performance check every few months, not after someone complains.

---

If your site has drifted into this territory and you would like someone to tell you which of the six applies to you, send me the URL. I will look at it properly and give you a straight answer about what is actually costing you the seconds — no charge and no pitch.