How to Speed Up WordPress Hosting: A Practical 2026 Guide

Most “slow WordPress” problems aren’t WordPress at all. They’re the hosting underneath it: an old PHP version, no object cache, a database full of junk, and a server that’s oversold. Here’s how I actually approach speeding up a WordPress site in 2026, roughly in the order that gives you the biggest win for the least effort.

Start by measuring, not guessing

Before you change a single setting, get a baseline. Otherwise you’ll never know what helped. I use two tools:

• PageSpeed Insights / Lighthouse for the front-end picture (LCP, CLS, TTFB).
• Query Monitor (a plugin) for the back-end picture: slow queries, slow plugins, HTTP calls.

Watch TTFB specifically. If your time to first byte is over 600ms on a cached page, the problem is the server, not your theme. That’s a hosting conversation, not a CSS one.

1. Get on a current PHP version

This is the single most common free win I find. If you’re on PHP 7.4, you’re running software that stopped getting security updates in 2022 and is meaningfully slower than modern PHP. As of 2026, PHP 8.3 and 8.4 are the versions you want. PHP 8.1 and 8.2 are in security-only support.

Check your version from the command line:

php -v
# PHP 8.3.x (cli)

Or from WordPress, drop this into a plugin or your theme’s functions file temporarily:

add_action( 'admin_notices', function () {
 echo '<div class="notice notice-info"><p>PHP: ' . esc_html( PHP_VERSION ) . '</p></div>';
} );

Before you flip the switch on production, test on staging. Most modern plugins and themes are fine on 8.3, but old custom code with deprecated functions can throw warnings. Fix those, don’t suppress them.

2. Use real page caching, and understand what it caches

Page caching stores the finished HTML so PHP and MySQL don’t run on every request. On a decent host with a proper cache, a cached page should serve in well under 200ms.

Options I’d actually recommend in 2026:

• Host-level caching (LiteSpeed Cache, or whatever your host provides). Best performance because it runs at the web server layer.
• WP Rocket or FlyingPress if you want a plugin that handles page cache plus asset optimization cleanly.
• W3 Total Cache or WP Super Cache if you need free and are willing to configure it yourself.

One trap: caching doesn’t help logged-in users or WooCommerce carts by default. If your site is dynamic, you need to exclude those pages and lean harder on object caching instead.

3. Add object caching (this is the one people skip)

Page cache handles anonymous visitors. Object caching handles everything else: logged-in users, admin screens, and the database queries that run before a page cache can even be built. WordPress supports a persistent object cache via Redis or Memcached.

If your host offers Redis, enable it, then install the Redis Object Cache plugin. If you’re on a VPS, install the PHP extension and the server:

sudo apt update
sudo apt install redis-server php8.3-redis
sudo systemctl enable --now redis-server

Then confirm WordPress is using it. In wp-config.php, you can point it at your Redis instance:

define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_TIMEOUT', 1 );
define( 'WP_REDIS_READ_TIMEOUT', 1 );
define( 'WP_CACHE', true );

On a site with a heavy plugin stack, object caching often cuts admin and logged-in page times in half. It’s not glamorous, but it works.

4. Clean up the database

Every WordPress install accumulates cruft: post revisions, expired transients, spam comments, orphaned metadata. On a site that’s been running for years, this can be hundreds of megabytes of dead weight that slows down every query.

You can prune revisions with a config constant:

define( 'WP_POST_REVISIONS', 5 );

And clean up expired transients directly, if you’re comfortable in the database:

DELETE FROM wp_options
WHERE option_name LIKE '_transient_timeout_%'
AND option_value < UNIX_TIMESTAMP();

Back up first. Always. For routine cleanup I’ll use WP-Optimize or the cleanup tools in a caching plugin, but I run the manual queries above on sites where I want to see exactly what’s being removed.

5. Optimize images and serve them in modern formats

Images are usually the largest thing on the page. In 2026 there’s no excuse for serving a 2MB JPEG to a phone.

• Convert to WebP or AVIF. AVIF is smaller but slower to encode; WebP is the safe default.
• Use responsive srcset so mobile gets a smaller file.
• Lazy-load anything below the fold, but never lazy-load your LCP image.

A plugin like ShortPixel or Imagify handles the conversion and rewriting automatically. If you’re doing it by hand in a theme, the pattern looks like:

<picture>
 <source srcset="hero.avif" type="image/avif">
 <source srcset="https://i0.wp.com/www.kennykey.com/hero.webp" type="image/webp">
 <img src="hero.jpg" width="1200" height="630"
 alt="Descriptive alt text" loading="eager" fetchpriority="high">
</picture>

The fetchpriority="high" on your hero image is a real Core Web Vitals win. Don’t skip it.

6. Trim the plugin stack

Every active plugin adds PHP to load and often queries to run. I’ve seen sites with three caching plugins, two SEO plugins, and a page builder fighting each other. Deactivate anything you’re not actively using. If two plugins do the same job, pick one.

To find the worst offenders, use Query Monitor’s “Queries by Component” view. It names the plugin responsible for each slow query. That’s how you make an evidence-based decision instead of guessing.

7. Pick hosting that isn’t fighting you

Shared hosting on a $3/month plan will always be a ceiling. If you’ve done everything above and TTFB is still bad, the server is the problem. What to look for in 2026:

• PHP 8.3+ by default, with per-site version control.
• Redis or Memcached available.
• NVMe storage and HTTP/3 support.
• A real staging environment.
• Server-level caching you don’t have to bolt on yourself.

Managed WordPress hosts (Kinsta, WP Engine, Rocket.net, and similar) cost more but usually pay for themselves in the hours you stop spending on server maintenance. If you’re local to the Northeast and want lower latency for regional visitors, a host with East Coast data centers helps, but honestly, a CDN matters more than geography for most sites.

8. Put a CDN in front of it

A CDN caches your static assets at edge locations worldwide and offloads a chunk of traffic from your origin. Cloudflare’s free tier is enough for most sites. If you’re already paying for a host that includes a CDN, use that. The goal is the same: fewer requests hitting your server, and faster delivery to visitors who aren’t near your data center.

What to do first if you only have an hour

In order: check PHP version, install a page cache, enable Redis if your host offers it, run an image optimization pass, then re-measure with PageSpeed Insights. That sequence gets most sites from “slow” to “fine” without touching a line of theme code.

If you’re past that point and the site is custom, or you’ve inherited something messy, the work shifts from settings to code. That’s the kind of thing I handle through custom web development, and it’s usually paired with Long Island SEO work, since speed and rankings are the same conversation in 2026. Core Web Vitals are a ranking input, and a fast site converts better regardless.

FAQ

Do I really need Redis, or is page caching enough?

For a simple brochure site with anonymous visitors, page caching is usually enough. Once you have e-commerce, membership, or a busy admin, object caching makes a noticeable difference and is worth the setup.

Will switching hosts fix my speed problems?

Only if the server is actually the bottleneck. Measure TTFB on a cached page first. If it’s high, yes, a better host helps. If it’s low and the page is still slow, the problem is on the front end or in your plugin stack.

How much should I expect to pay for fast WordPress hosting?

Realistically, $20 to $50 a month for a solid managed plan on a single site, more for high-traffic or WooCommerce. Below that, you’re usually trading money for your own time in server maintenance.