How to Speed Up a WordPress Website in 2026 (What Actually Works)

Most site owners come to me with the same sentence: the site feels slow, and nobody can tell them why. They have installed three caching plugins, run a few tests, and the score barely moved. If you want to speed up a WordPress website properly, the work is less about stacking plugins and more about fixing the handful of things that genuinely control load time.

Here is the order I actually work in on client projects, and why each step matters more than the one after it.

Measure the right thing first

A performance score out of 100 is a summary, not a diagnosis. What matters to your visitors, and to Google, are Core Web Vitals: Largest Contentful Paint (how quickly the main content appears), Interaction to Next Paint (how quickly the page responds when someone taps or clicks), and Cumulative Layout Shift (whether things jump around while loading).

Test on a real mobile connection, not just your office wifi on a desktop. Test the pages that actually receive traffic, which is usually the homepage, one service page, and one blog post. A homepage that loads in 1.2 seconds means little if your best-converting landing page takes six.

Run each test three times and take the median. Single runs vary enough to send you chasing problems that are not there.

Hosting is the ceiling everything else runs into

This is the part people least want to hear, because it costs money and cannot be fixed with a plugin. Server response time, often reported as Time to First Byte, is the floor under every other optimisation. If your server takes 900 milliseconds to return the first byte, no amount of image compression brings your load time under a second. It is arithmetic.

Cheap shared hosting packs hundreds of sites onto one machine. Your site is competing for resources with strangers. When I move a client from budget shared hosting to decent managed WordPress hosting, TTFB commonly drops from around 800 milliseconds to under 200, and every subsequent fix builds on that.

Also check your PHP version. Sites still running PHP 7.4 are leaving significant performance on the table compared to PHP 8.3, and the upgrade is usually free.

Images are the biggest win on most sites

On the majority of sites I audit, images account for more of the page weight than everything else combined. Someone uploaded a 4000 pixel wide photograph straight from a phone into a slot that displays at 600 pixels, and WordPress dutifully serves a scaled-down version of an enormous file.

Three fixes, in order of impact:

• Serve modern formats. WebP typically cuts file size by 25 to 35 percent against JPEG at equivalent quality. AVIF goes further still.
• Resize before compressing. Compression on an oversized image is treating the symptom. Get the dimensions right first.
• Lazy load below the fold, but never the hero. Lazy loading your LCP image actively delays the metric you are trying to improve. This mistake is extremely common.

Always set explicit width and height attributes. Without them the browser cannot reserve space, and your layout shifts as images arrive, which damages CLS.

Plugin bloat costs more than the plugin count suggests

I have never found a magic number of plugins that is too many. Thirty lightweight plugins can outperform eight badly built ones. What matters is what each plugin loads and where.

The common pattern is a plugin that enqueues its CSS and JavaScript on every single page, when it is used on exactly one. A contact form library loading on all 200 pages of your site is a real cost paid on every visit.

When I audit a site, I look for plugins doing work on the front end that could be limited to the pages that need them, plugins duplicating functionality already in the theme, and plugins abandoned by their developers. Removing three heavy plugins usually beats adding a fourth optimisation plugin.

Caching and file optimisation, in that order

Page caching gives the largest single improvement of any plugin-level change, because it skips PHP and database work entirely for repeat visitors. Get that working before touching anything else.

Then minification and file combining, carefully. Deferring JavaScript and eliminating render-blocking resources helps genuinely, but aggressive settings break things, and they break things silently. Test your contact forms, your checkout, your sliders and your mobile menu after every change. I turn on one setting at a time and check the site between each.

Add a CDN when your audience is geographically spread. If your clients are all in one city, a CDN is a smaller win than fixing your images.

Page builders are not automatically slow

There is a persistent belief that Elementor sites are inherently slow. In my experience the builder is rarely the problem. Deeply nested sections, six different font families, and animation on every element are the problem.

Practical habits that keep builder sites fast: limit yourself to two font families and only the weights you use, avoid stacking containers inside containers when one will do, use the builder own performance settings rather than fighting them with a third-party plugin, and keep global styles global instead of overriding them per widget.

The same applies to dynamic content. A directory or booking site querying hundreds of posts on the front page needs the query itself optimised. No caching plugin rescues a badly built query.

The database nobody maintains

After a few years, a WordPress database accumulates thousands of post revisions, expired transients, orphaned metadata and tables belonging to plugins deleted long ago. It rarely causes a dramatic slowdown, but it makes backups slower and admin pages sluggish.

Clean it periodically, always with a backup taken first. Limit stored revisions rather than deleting them all, because revision history is genuinely useful.

What realistic results look like

On a typical brochure or service site with reasonable hosting, this sequence usually brings load times into the one to two second range on mobile and moves Core Web Vitals into the green. On a large WooCommerce store with heavy customisation, expect improvement rather than perfection, because carts and accounts cannot be fully cached.

Be sceptical of anyone promising a perfect score. A perfect score on a synthetic test is not the goal. A site that feels immediate to a real person on a phone with average signal is the goal, and those two things are not the same measurement.

Speed work also has a shelf life. Plugins update, content gets added, someone uploads a huge image. Sites drift back without periodic attention, which is why I include performance checks in my ongoing maintenance work rather than treating optimisation as a one-off task.

If you would rather hand this work over, see my WordPress speed optimization service.

Where to start tomorrow

If you only do three things: check your server response time, fix your images, and audit what your plugins load on the front end. That covers most of the gap on most sites.

If you would rather not spend a weekend on it, or you have tried and the numbers have not moved, I am happy to take a look. You can see examples of the kind of work involved in my portfolio, or request a free quote and tell me what your site is doing. I will tell you honestly whether it needs a few hours of work or something more structural.