Skip to main content

Blog · WordPress

WordPress speed in 2026: the fixes that actually delivered

By the Hosting & Domains team Published 27 July 2026 8 min read

"My WordPress site is slow" begins more support conversations than nearly anything else, and after enough of them a pattern shows itself. A few changes do almost all the work, most of them structural and none of them glamorous, while a great deal of owner energy disappears into tuning that shifts nothing. What follows is that pattern, taken straight from the tickets and ordered by what each change actually returned.

First, a definition. Fast in 2026 means Google's Core Web Vitals, and above all LCP under 2.5 seconds on a mid-range phone. A lab run on your own desktop is trivia. Phones on mobile networks are where the traffic actually is.

The four fixes that pulled real weight

1. Server-level page caching. Nothing else comes close. A cached page bypasses PHP and MySQL altogether and leaves the server in a millisecond or two. On a LiteSpeed host, install the free LiteSpeed Cache plugin and switch page caching on. That one setting routinely beats everything else in this article put together. Our setup guide takes about ten minutes.

2. Getting the images under control. Overweight images are the commonest cause of a failed LCP we see. Convert to WebP, export each image at the size it is actually displayed, and let anything below the fold lazy-load, which WordPress now does by itself. The image optimisation guide walks through the whole workflow.

3. Auditing plugins by weight rather than by number. Twenty light utilities cost less than one page builder hauling 400 assets into every load. Query Monitor is free and will identify the offenders in an afternoon. The usual suspects are page builders, related-posts engines, and anything phoning home on every request.

4. The PHP version. Every major release since 8.0 has brought a real speed gain, so a site left on 8.1 is giving performance away for nothing. The upgrade is a dropdown in the control panel and a five-minute compatibility check.

The tuning that eats weekends and returns nothing

Minifying CSS and JavaScript by hand. Modern themes arrive minified, and bolting a second minifier over the top breaks more sites than it accelerates. The gain, on a good day, rounds to nothing.

A CDN for a single-country audience. When every customer is in one place and the host caches properly, a CDN mostly adds a network hop for nothing. It starts earning its fee when analytics show real international traffic, and not a day earlier.

Running two cache plugins at once. They do not cache twice; they fight. Keep whichever one is built for your server, LiteSpeed Cache on a LiteSpeed box, and remove the others.

Polishing desktop Lighthouse scores. A 100 on a gaming laptop sits quite happily beside a 55 on a phone. Test mobile, and test throttled. That is the figure Google marks and the page your readers actually get.

When the platform is the bottleneck

Some tickets point at the hosting rather than the plugin stack. The signs are a TTFB above roughly 600ms on a page that is already cached, healthy scores that fall apart under light concurrency, and unexplained mid-afternoon slowdowns, which nearly always mean a noisy neighbour on an oversold box. No plugin mends any of that.

The remedy there is the layer underneath. NVMe storage answers database queries in microseconds where SATA took milliseconds, and LiteSpeed holds its pace under concurrent load in a way stock Apache never does. That is the whole case for our WordPress hosting: we keep the platform quick, which leaves only the four fixes above on your list.

Hosted elsewhere and suspicious? Time the TTFB on a cached page once at a quiet hour and once at peak. A wide gap means too many accounts fighting over too little server, and no image compressor outruns that. Moving to us costs nothing, so the experiment is cheap.

Quick answers

What one change speeds WordPress up the most?

Server-level page caching, every time. On a LiteSpeed box, that is the LiteSpeed Cache plugin with page caching switched on. A cached page never reaches PHP or the database, and that saving dwarfs every asset-level tweak combined.

Does a WordPress site need a CDN?

Only if your readers really are spread across countries. With a single-country audience on a properly cached host, a CDN tends to add latency and moving parts for nothing measurable. Look at the geography report in your analytics before paying for one.

How do I tell whether the hosting is what is slowing WordPress down?

Time the TTFB on a cached page. If it sits above roughly 600ms, or races at 7am and crawls at 4pm, the drag is contention on the platform rather than anything on your site. No plugin mends that pattern.

Up next

More from the blog

The platform these posts come from

Renewals that stay flat, limits printed before you buy, migration at no charge and a support desk that writes back, all wrapped into one plan.

Browse Hosting Plans