How to fix a slow WordPress website

A slow website is the cheapest problem to ignore and one of the most expensive to keep. Visitors do not file a complaint, they just leave, and you never find out. If your site takes six seconds to load on a phone, a good share of the people who searched for your business and clicked your listing never saw your page at all.

The good news is that WordPress slowness is rarely mysterious. It is almost always the same handful of causes, in roughly the same order of impact. Here is how to find yours and what to do about it.

First, measure. Do not guess.

Your own impression of the site is unreliable, because your browser has already cached it. Before you change anything, get a number you can compare against later.

• PageSpeed Insights (pagespeed.web.dev) is the one that matters most, because it reports the same Core Web Vitals Google uses. Run it on your homepage and on one interior page, and read the Mobile tab first. Mobile is where the problem usually lives.
• Largest Contentful Paint (LCP) is the headline number: how long until the biggest thing on screen appears. Under 2.5 seconds is good. Over 4 seconds is costing you visitors.
• Time to First Byte (TTFB) tells you whether the delay is your server or your page. A slow TTFB means the problem is hosting or a lack of caching, not your images.

The usual causes, in order of impact

1. Oversized images

This is the single most common cause we find, and the easiest to fix. Someone uploads a photo straight off a phone or a stock site at 4,000 pixels wide and several megabytes, and WordPress displays it in a 600 pixel space while still making every visitor download the whole thing. Ten of those on a page and the site is finished before it starts.

• Resize images to roughly the size they actually display at before uploading. For most content images that means 1,600 pixels wide at most.
• Save as WebP where you can, or use an image optimization plugin that generates WebP versions automatically.
• Make sure images below the fold are lazy loaded. Modern WordPress does this by default, but page builders sometimes override it.

2. No caching, or a slow host

Without caching, WordPress rebuilds every page from the database on every single visit. Caching saves a finished copy and serves that instead, and it is usually the biggest single speed win after images. If your TTFB was slow in the measurement step, start here.

• Check whether your host already provides server-level caching. Many managed WordPress hosts do, and adding a second caching plugin on top can cause conflicts rather than gains.
• If not, one well-configured caching plugin is enough. One. Not three.
• If your TTFB is still poor with caching on, the host itself is the ceiling. Cheap shared hosting oversells its servers, and no plugin fixes that.

3. Page builder bloat

Elementor, Divi, WPBakery, and similar tools are convenient, and they charge for that convenience in page weight. A builder typically loads its full CSS and JavaScript framework on every page whether the page uses it or not, plus wraps your content in layers of nested markup. On a simple brochure site that overhead can be most of your load time.

You do not necessarily have to abandon a builder you have already invested in. But if you have measured and the builder framework is a large share of the payload, that is worth knowing, and it is the main reason we build client sites in hand-written code instead.

4. Too many plugins, and the wrong ones

The count matters less than what each one does. Five lightweight plugins are fine. One badly written slider that loads jQuery on every page is not. Look for plugins that add front-end assets sitewide, plugins doing work on every page load, and anything you installed once and forgot.

• Deactivate and delete plugins you do not use. Deactivated plugins are still a security liability.
• Be suspicious of anything with "all in one" in the name that you only use one feature of.
• Statistics and analytics plugins that run inside WordPress are a common hidden cost. Use a hosted analytics service instead.

5. Third-party scripts

Chat widgets, tracking pixels, review carousels, embedded maps, custom fonts, and booking widgets are all requests to somebody else's server, and their speed is not under your control. A single chat widget can add a second or more. Audit what is actually earning its place, and remove the pixel from the ad campaign you stopped running two years ago.

6. A bloated database

Less dramatic, but real on older sites. Years of post revisions, spam comments, expired transients, and orphaned data from deleted plugins accumulate in the database. The usual culprit is autoloaded options, which WordPress reads on every page load. This one is worth having someone technical look at rather than firing a cleanup plugin at it, because the wrong delete is not easily undone.

What to do, in what order

Change one thing at a time and re-measure. If you change six things at once and the site gets slower, you have learned nothing.

1. Take a full backup first. Offsite, and confirm it exists before touching anything.
2. Fix your images. Resize the worst offenders, enable WebP, confirm lazy loading works.
3. Get caching working properly, using either your host's caching or one plugin, not both.
4. Remove plugins and third-party scripts you do not use or need.
5. Re-measure on mobile. Compare against the numbers you wrote down.
6. If LCP is still poor, look harder at your page builder and your host, in that order.

What not to do

• Do not install several optimization plugins at once. They fight over the same files, and the usual result is a broken layout that is no faster.
• Do not enable every toggle in a caching plugin. Aggressive JavaScript combining and deferring is the most common cause of a site that suddenly looks broken after "optimization."
• Do not buy a speed plugin to compensate for bad hosting. If TTFB is the problem, that is a hosting decision, not a plugin decision.
• Do not optimize without a backup. The whole point of these changes is that they alter how the site is delivered.

When it is worth calling someone

If you have handled the images and caching and the site is still slow, what is left is generally diagnostic work: reading a waterfall chart, profiling database queries, or finding the one plugin that is quietly running on every request. That is where hours disappear if it is not something you do regularly.

It is also worth getting help immediately if the site is slow and behaving oddly. Sudden unexplained slowness on a site nobody has changed is sometimes a symptom of a compromise rather than a performance problem.