How to Speed Up WordPress on Shared Hosting

A slow WordPress site on shared hosting is almost never one problem. It is usually four, and they compound: no page cache, an old PHP version, images straight from a phone camera, and a database nobody has cleaned since 2019.

The trouble with most speed guides is that they list every possible fix as though each one matters equally. They do not. Enabling a page cache can cut your load time by 80%; deferring a font can save 40 milliseconds. Both appear as "tip #7" somewhere.

So this guide is ordered by effect. Do them in sequence, measure after each one, and stop when the site is fast enough. Most sites never get past step four.

First, measure — properly

Before changing anything, get two numbers.

Time to First Byte (TTFB) is the server's responsibility. Run this against your own homepage:

curl -o /dev/null -s -w "ttfb: %{time_starttransfer}s  total: %{time_total}s\n" https://yoursite.com/

Run it five times. Take the median, not the best. Under 200 ms is good, 200–500 ms is fixable, over 800 ms means the server is doing far too much work per request — which is what steps 1 to 3 address.

Largest Contentful Paint (LCP) is what the visitor feels. Get it from PageSpeed Insights, and read the field data section if it appears — that is real visitors, not a lab simulation. The lab score is a useful diagnostic and a terrible target.

One caution: test the same page each time, logged out, in a private window. WordPress bypasses the page cache for logged-in users, so testing while logged into the admin measures a site nobody else is using.

Step 1 — Turn on a page cache

This is the single biggest change available to you, and on many sites it is the only one that matters.

Without a cache, every visit runs PHP, queries MySQL a few dozen times, assembles the page and sends it. With one, the first visit does that and every subsequent visit gets a stored HTML file. The work drops to nearly nothing.

Which plugin depends on what your host runs, and this is the part most guides get wrong:

Find out which you have: your cPanel will say, or run curl -I https://yoursite.com/ and look at the server header.

The important detail: LiteSpeed Cache only delivers its headline performance on a LiteSpeed server. Installed on Apache it falls back to ordinary PHP-level caching and is just another plugin. If a guide tells you it is the fastest plugin without mentioning that, it has not tested it.

Two settings worth changing from the defaults on shared hosting:

• Turn the crawler off. It pre-warms the cache by making real HTTP requests to your own site in the background, which burns exactly the CPU and entry-process budget your plan is limited on.
• Exclude the cart, checkout and account pages if you run WooCommerce. Caching those serves one customer another customer's basket.

Step 2 — Update PHP

WordPress runs on PHP, and PHP has got dramatically faster. Sites still running PHP 7.4 are leaving roughly half their performance on the table compared with PHP 8.3, on identical hardware and identical code.

In cPanel, look for MultiPHP Manager or Select PHP Version. Change it, then load every important page and the admin.

Two rules make this safe:

1. Move one version at a time, and test in between. 7.4 → 8.0 → 8.1, not 7.4 → 8.3.
2. Know how to go back. The selector reverts in seconds, which is exactly why a host without one is a problem.

If something breaks it is essentially always an abandoned plugin. That plugin was going to break eventually anyway, and now you know which one.

While you are in there, enable OPcache if your host exposes the setting. It keeps compiled PHP in memory instead of recompiling it on every request, and it is free performance.

Step 3 — Fix the images

On most WordPress sites images are the majority of the page weight, and the usual cause is that somebody uploaded a 4 MB, 6000-pixel-wide photo from a phone into a slot that displays it at 800 pixels.

Three things, in order:

1. Resize before uploading. Nothing beats not sending the bytes. If the widest slot in your theme is 1600px, no image needs to be wider.
2. Serve WebP or AVIF. They are 25–50% smaller than JPEG at the same visual quality. Most caching plugins convert and serve them automatically — LiteSpeed Cache and the common image plugins all do.
3. Lazy-load below-the-fold images — WordPress does this natively now — but explicitly exclude your LCP image. Lazy-loading the hero image delays the exact thing LCP measures, and this is the most common way a well-meant optimisation makes the score worse.

Skip the "optimise 10,000 images in the media library" step until you have done the first three. Most of those images are not on any page anybody visits.

Step 4 — Clean the database

WordPress stores every revision of every post forever by default. A page edited two hundred times is two hundred rows, and wp_options accumulates orphaned rows from every plugin ever installed.

The highest-value fix here is one line in wp-config.php:

define( 'WP_POST_REVISIONS', 5 );

That caps revisions at five per post going forward. Then delete the existing backlog, expired transients and spam comments — any of the maintenance plugins will do it.

Take a backup first. Database cleaning is the one step on this list that can genuinely destroy a site, and "optimise" buttons in plugins are not always reversible.

One thing to look for specifically: autoloaded options. Every row in wp_options marked autoload is loaded into memory on every single request. A plugin that stores a large blob there taxes every page view on the site. You can find the worst offenders in phpMyAdmin:

SELECT option_name, LENGTH(option_value) AS size
FROM wp_options WHERE autoload = 'yes'
ORDER BY size DESC LIMIT 20;

Anything over a few hundred kilobytes in that list is worth investigating.

Step 5 — Audit the plugins

Not the count — the cost. Thirty well-written plugins can be cheaper than three bad ones.

Install Query Monitor, load a slow page, and look at which plugin owns the slowest queries and the longest PHP time. That turns "I have too many plugins" into "this one plugin costs 400 ms per request", which is something you can act on.

The usual culprits: page builders, sliders, related-post plugins that run an unindexed query on every load, statistics plugins that write to the database on every page view, and anything that phones an external API during a page render.

For the last category, the fix is often to move the work to WP-Cron rather than removing the feature.

Step 6 — Put a CDN in front

A CDN serves your static files from a location near the visitor and absorbs a large share of your traffic before it reaches the server. On shared hosting that second part matters as much as the first, because it lowers the load on a machine you are sharing.

Cloudflare's free tier is genuinely sufficient here. The Cloudflare with shared hosting guide covers the setup, including the two settings that cause most of the problems people blame on Cloudflare.

Three fixes that do nothing on shared hosting

Time not wasted is time saved.

• "Increase your PHP memory limit to 1 GB." If you are not hitting a memory error, this changes nothing. Memory limit is a ceiling, not an allowance.
• Object caching with Redis or Memcached. Excellent advice — for a VPS. Most shared plans do not offer either, and a file-based object cache on a contended disk can be slower than no object cache at all.
• Switching to a "faster" theme, first. A heavy theme is a real problem, but rebuilding your site is a big change with a slow feedback loop. Do steps 1 to 4 first; quite often the theme turns out not to have been the problem.

When it is the host, not the site

If TTFB is still high after a page cache is confirmed working, the server is the bottleneck. Two ways to tell:

• TTFB is fine at 4am and terrible at 9pm. The machine is oversold. No plugin fixes that.
• A cached, static HTML page is still slow. Nothing of yours is running. That is the server or the network.

The second one is often distance rather than load. A server in the United States serving visitors in Dhaka pays a full intercontinental round trip on every request, and ours run in Dhaka on BDIX-connected servers, which is the difference between 30 ms and 300 ms for a Bangladeshi visitor. If your audience is Bangladeshi and your host is not, that single move will beat every optimisation on this page combined.

A realistic order of work

For a typical slow WordPress site, here is where the time actually goes:

Measure after each. If you are under 200 ms TTFB and a 2.5 second LCP, you are done — further work has a much worse return than almost anything else you could spend the afternoon on. And if the work is not something you want to spend the afternoon on at all, this is the kind of work we do if you would rather hand it over.

Frequently asked questions

Why is my WordPress site slow even with a caching plugin? Usually the cache is not actually serving. Check in a private window while logged out — WordPress bypasses the cache for logged-in users, so an administrator sees the uncached site and assumes nothing changed. Also check that the plugin matches your server: LiteSpeed Cache on an Apache host does a fraction of what it does on LiteSpeed.

Does the number of plugins slow WordPress down? Not directly. The cost is what they do per request, not how many there are. Use Query Monitor to find the expensive ones rather than deleting by count.

Is shared hosting too slow for WordPress? No, for the great majority of sites. A well-run shared plan on NVMe with a working page cache will serve tens of thousands of monthly visits comfortably. You have outgrown it when you need system-level software or you are permanently at your resource ceiling — see shared vs VPS vs dedicated.

What is a good TTFB for WordPress? Under 200 ms is good and achievable on shared hosting with caching. 200–500 ms is workable. Consistently over 800 ms means either no cache is running or the server is overloaded or far from your visitors.

Will updating PHP break my site? It can, and always on an abandoned plugin. Move one version at a time, test the admin and the important pages, and use the PHP version selector to revert if needed. A plugin that cannot run on a supported PHP version is a security problem regardless of speed.