Why Your WordPress Site Is Slow

The site was quick when it launched. Two years on it takes several seconds to appear and everyone assumes the hosting has degraded. Occasionally that is true. Usually it is not.

WordPress gets slow through accumulation. Nothing dramatic happens, a little weight gets added every month, and eventually it shows.

Page builders are usually the biggest single cause

Drag and drop builders let anyone lay out a page, and that convenience has a cost. They generate deeply nested markup and load their own stylesheets and scripts on every page, whether the page uses those features or not.

A layout that would be a few dozen lines of HTML written directly can be several hundred through a builder, plus a couple of hundred kilobytes of supporting code.

You do not have to abandon your builder. But if speed genuinely matters, know that this is where a large part of the weight comes from, and that no amount of caching removes it entirely.

Plugin sprawl

Every plugin is more code running on every request. Many load their assets site-wide even when they are only used on one page. A contact form plugin loading its scripts on your home page is completely normal and completely wasteful.

Open the plugin list and go through it honestly. Anything deactivated should be deleted, not left in place. Anything that duplicates what another plugin does should go. Anything you added for a campaign that finished should go.

Test after each removal rather than in a batch, so you know what broke what.

Images nobody resized

This is the most common and the easiest to fix. Someone uploads a photo straight from a phone or a stock library, several thousand pixels wide, and the browser scales it down to fit a 600 pixel slot after downloading all of it.

Three things fix most of it. Resize images to roughly the size they will display at. Use a modern format such as WebP. Set width and height so the browser reserves the space and the page does not jump while loading.

That last point is not only about speed. Content jumping around during load is measured by search engines and it is genuinely annoying to use.

Fonts

Custom fonts are heavier than people expect. Each weight and style is a separate file. A site loading four weights in two styles is downloading eight files before text renders properly.

Use two weights unless there is a real reason for more. Serve them from your own server rather than a third party where possible, and set them to display fallback text immediately rather than leaving a blank space while the font arrives.

Third party scripts

Analytics, chat widgets, heatmaps, advertising pixels, embedded videos. Each one is a request to a server you do not control, and your page waits on it.

A chat widget is often heavier than the entire rest of the page. If it is genuinely bringing in enquiries, keep it. If it was added a year ago and nobody checks it, remove it.

For anything that stays, load it after the page rather than during. The user does not need a chat widget in the first second.

The database gets heavy too

WordPress accumulates rubbish in the database. Post revisions, settings left behind by deleted plugins, expired temporary records.

On a site running for years this builds up enough to slow the queries that run on every page load.

It can be cleaned, but take a backup first. Database cleanup is not reversible and the wrong plugin choice can delete content.

Caching helps, but it is not the fix

Caching stores a finished version of the page so the server does not rebuild it for every visitor. It genuinely helps and it should be on.

What it does not do is make a heavy page light. If your page ships two megabytes of images and scripts, caching delivers those two megabytes faster. The visitor still downloads all of it.

Caching is worth doing first because it is easy. It is not a substitute for reducing what the page contains.

Does changing host help?

Sometimes, but not as often as people hope. Server response time is one part of total load time, not all of it.

Test it properly. In any speed tool, find the server response time figure. If it is high, better hosting is worth considering. If it is low, the delay is happening in the browser and a new host changes nothing.

If you do move, make sure addresses stay identical. Gaining speed and losing rankings is a poor trade.

What to measure and where

Lab tools run a simulated test from a data centre. Field data is what real visitors experienced. They disagree often, and field data is the one that counts.

Search Console reports field data grouped into good, needs improvement and poor. That grouping is more useful than a single score because it tells you what proportion of real visitors are having a bad time.

Test on mobile with throttling on. Testing a site on a fast desktop connection tells you almost nothing about the experience most of your visitors are having.

Do not chase the score

Speed tools give a number out of a hundred and people treat it as the goal. It is not.

What matters is what a real visitor experiences on a real phone on a real connection. Breaking a working feature or degrading an image to move a score from seventy to eighty is a loss dressed as a win.

A reasonable target is that the page becomes usable within a couple of seconds on mobile and does not jump around while loading. Once that is true, the exact score is a detail.

The order worth working in

1. Resize and compress images. Biggest gain, least risk.
2. Remove plugins you do not use. Free speed and a smaller attack surface.
3. Turn on caching if it is not already on.
4. Cut fonts back to what you actually use.
5. Audit third party scripts and defer what survives.
6. Clean the database, after a backup.
7. Only then consider hosting or a rebuild.

Most sites we look at get most of their improvement from the first three, and those are the three anybody can do without a developer.

When a rebuild is the honest answer

If the site is built on a heavy builder, carries fifteen plugins that are all doing something, and needs to be fast, you are optimising around a structural problem.

Rebuilding without the builder and without the plugin stack produces a site that is faster by default rather than faster after tuning. It also costs money, so it is worth doing the cheap fixes first and seeing where that lands you.

We rebuilt a client site that had been running on WordPress with a builder for years. The design and copy stayed identical on purpose. What changed was everything underneath, and the difference was immediately visible on mobile.