Most WordPress sites are slow for one of four reasons: the server rebuilds every page from scratch on every visit, the database has filled with rows nobody reads, images are being sent at several times the size they are displayed, or a plugin does work on every request that it only needs to do once a day. Almost everything else is a detail. This guide works through those four in the order that gives the biggest improvement for the least risk, and shows you how to confirm each change actually did something rather than trusting a plugin's dashboard.
Before changing anything, take a measurement you can compare against later. Load your homepage and one deep page (a single post, or a product page) and write down the time to first byte and the total load time. Without a baseline you cannot tell the difference between a real improvement and a page that happened to be cached when you tested it.
Turn on caching at the server, not only in a plugin
A page cache stores the finished HTML of a page so the next visitor receives that file instead of making WordPress build the page again. Where that cache lives matters enormously. A PHP-based caching plugin still has to start PHP, load WordPress and load the plugin itself before it can hand back the stored copy. A cache that lives in the web server answers before PHP is ever involved.
Ahosting runs LiteSpeed, so that fast path is available without extra software: install the LiteSpeed Cache plugin from the WordPress plugin directory and enable caching in its settings. The plugin does not perform the caching itself. It tells the web server what to store and when to discard it. That is why it behaves differently from plugins that keep the cache inside the PHP layer, and why advice written for a general Apache host does not transfer directly.
Two settings do most of the work: enable the page cache, and enable object caching if your plan offers it. Leave the more aggressive options alone at first. Combining and deferring CSS and JavaScript can break themes in ways that only appear on some pages, and you want to be able to attribute any problem to a single change.
Confirm it is working rather than assuming. Load a page in a private browsing window, load it again, and check the response headers for a cache hit indicator. If the second load does not report a hit, the cache is not engaging and no amount of further tuning will help.
Understand what caching cannot do for you
Page caching only helps visitors who are not logged in and have nothing user-specific on the page. A logged-in editor, a customer with items in a cart, and a checkout page all bypass the cache by design, because serving one shopper another shopper's cart would be far worse than a slow page.
This is why store owners often report that caching "did nothing". The homepage got much faster and the pages that actually decide whether a sale completes did not change at all. If your site is mostly cart and account pages, your improvement will come from the next three sections, not from the cache.
Find the plugin that is costing you the most
Plugins are the most common cause of a slow WordPress site, but "too many plugins" is the wrong way to think about it. Thirty well-written plugins that do nothing on the front end cost less than one plugin that runs a database query on every page load.
Install a query monitoring plugin, load a slow page while signed in as an administrator, and read which plugin accounts for the largest share of query time and PHP time. The result is often surprising: related-post widgets, visitor counters, sliders and "recent activity" panels tend to dominate, because they query the database on every request without caching the answer.
When you find the offender, decide honestly whether the feature earns its cost. A related-posts block that adds a noticeable delay to every page is rarely worth it. If the feature does matter, look for a version that caches its output instead of recomputing it.
Deactivate one plugin at a time and re-measure. Deactivating five at once tells you that something improved, not what.
Clean the database, then keep it clean
WordPress stores every revision of every post indefinitely unless told otherwise. A page edited fifty times leaves fifty rows behind. Add expired transients, spam comments and the leftovers of plugins uninstalled years ago, and the tables WordPress reads on every request are far larger than they need to be.
Take a backup first. Database cleanup is one of the few optimisations that can destroy content, and a bad plugin choice here is not recoverable without a copy.
With the backup confirmed, remove post revisions beyond a small number, delete spam and trashed comments, and clear expired transients. Then cap revisions going forward so the problem does not return, by adding a limit to wp-config.php:
define( 'WP_POST_REVISIONS', 5 );
Five revisions is enough to recover from a bad edit while keeping the table small. Setting this to false disables revisions entirely, which is usually a mistake; the storage saving is small, and the day you need to undo an edit you will want them.
Stop sending images larger than they are displayed
On most sites that have not been tuned, images are the largest part of the page by a wide margin. The usual cause is a photograph uploaded straight from a phone being displayed in a slot a fraction of its width. The browser downloads the full file and then scales it down, so the visitor pays for pixels they never see.
Three things fix nearly all of it. Resize images to roughly the largest size they will ever be shown before uploading. Use a modern format, WebP and AVIF are substantially smaller than JPEG at the same visual quality. And let images below the fold load lazily, which WordPress does by default for most themes.
An image optimisation plugin can handle conversion and compression for images already in your library. Check the result visually on a large screen afterwards; overly aggressive compression shows up first in photographs of skin and skies.
Run a current version of PHP
PHP performance has improved substantially across recent major versions, and running an old one leaves speed on the table for no benefit. You can change the version yourself, see how to configure PHP settings in cPanel for where the setting lives.
Move up one major version at a time and load the site afterwards, including the admin area and any checkout flow. Older plugins occasionally call functions removed in newer versions, and the failure is usually loud and immediate rather than subtle, which makes it easy to roll back.
Know the difference between a slow site and an overloaded account
If your site is fast at night and slow in the afternoon, caching and image sizing are not your problem. You are hitting a resource ceiling: the PHP processes your plan allows are all busy, and new requests queue behind them. The symptom is a page that hangs and then loads, rather than a page that is consistently sluggish.
Caching still helps here, and it helps a great deal, because every request served from cache is a request that never occupies a PHP process. But if you are consistently at the ceiling with caching already working, the honest answer is that the site has outgrown the plan and further tuning will not change that. Moving to VPS hosting with dedicated resources is the fix at that point.
Measure again, the same way you measured before
Test the same two pages you started with, from the same place, once with a cleared cache and once with a warm cache. Both numbers matter: the warm number is what most visitors see, and the cold number is what the first visitor after a change sees, and what a search engine crawler often gets.
Be careful with the first run after any deployment. It will be slower than normal because nothing is cached yet, and treating that single cold run as your result is the most common way people conclude a change made things worse when it did not.
A sensible order to work through
- Record a baseline for two pages, cold and warm.
- Enable server-level page caching and verify a cache hit in the response headers.
- Measure again. This is usually the largest single jump.
- Profile plugins, remove or replace the worst offender, measure again.
- Back up, then clean the database and cap post revisions.
- Resize and convert images, then confirm quality on a large screen.
- Move to a current PHP version, one major version at a time.
- If the site is only slow under load, review the plan rather than tuning further.
Where to go next
If the site is not merely slow but throwing errors under traffic, the pattern is different and worth reading separately, start with how to fix common WordPress errors. If you are preparing to move a site and would rather arrive on a tuned stack than optimise in place, moving an existing WordPress site goes over the migration path.
The official WordPress optimization documentation goes deeper on the application layer once the server-side work is done.
If your site has logged-in users, most of this does not apply to them. How to Host a Membership or Login-Based Site explains what does.
None of this reaches the admin area, which is never cached. How to Speed Up a Slow WordPress Admin goes into that side separately.