How to speed up WordPress: from hosting to the database
Measure first, then fix the stack from the bottom up: PHP and server caching, images, plugins, the database and the WooCommerce pages that cannot be cached.
Most slow WordPress sites are not slow for the reason their owners assume. Before installing another plugin, measure. Time to first byte (TTFB) tells you how long the server needs to produce the HTML; above roughly 600 ms on a cached page, the problem is on the server side. Largest Contentful Paint (LCP) tells you when the main content actually appears, and Google counts up to 2.5 seconds as a good score. Run PageSpeed Insights for field data from real visitors, then WebPageTest or your browser’s network tab to see what loads in which order. Write the numbers down: every change below should move one of them, and if it does not, undo it.
Start at the bottom of the stack, because no plugin can fix a slow server. Check the PHP version first: WordPress runs noticeably faster on PHP 8.x than on 7.x, and anything below 8.2 no longer receives security fixes. Make sure OPcache is enabled, so PHP keeps compiled code in memory instead of parsing the same files on every request. Storage matters too: WordPress reads hundreds of small files per page, and NVMe disks handle that far better than SATA SSDs. The biggest single gain, though, is a cache at the server level, where the web server returns a stored page without starting PHP at all.
This is where the choice of plan and the choice of caching plugin meet. On our WordPress hosting, anonymous visitors are served a cached page by the web server and PHP runs only for logged-in users and form posts, so a caching plugin’s job shrinks to purging the right pages when you publish. On hosting without a server-level cache, a plugin such as WP Super Cache, W3 Total Cache or WP Rocket writes static HTML files instead. Pick one, not two: stacked caching plugins fight over the same rules and serve stale or broken pages. If your server runs LiteSpeed, its own plugin is usually the best fit.
Images are usually the heaviest part of a page and the easiest to fix. Convert uploads to WebP or AVIF, which are typically 25–50% smaller than JPEG at the same visual quality; WordPress has supported WebP since version 5.8 and AVIF since 6.5. Never upload a 4000-pixel photo to show it at 800 pixels: WordPress generates several sizes and lets the browser pick the right one through srcset, but only if your theme outputs proper image sizes. Native lazy loading defers images below the fold, but the main hero image should load straight away, because lazy-loading your LCP element is one of the most common ways to make that score worse.
Every active plugin adds PHP code, and many also add database queries, scripts and stylesheets to every page, whether that page needs them or not. Use Query Monitor to see which plugins cost the most time, deactivate what you no longer use, and replace a page-builder theme with a lightweight block theme when the next redesign comes around. Then clean the database. Autoloaded options are read on every request, so keep their total well under a megabyte and remove leftovers from deleted plugins. Limit post revisions in wp-config.php, delete expired transients, and let WP-CLI or a cleanup plugin do it on a schedule rather than once.
WooCommerce changes the rules, because its most important pages cannot be cached. The cart, the checkout and the customer account are different for every visitor, so they must be excluded from the page cache, or one customer may see another’s basket. That means PHP and the database do real work on every step of the purchase. A persistent object cache such as Redis keeps the results of repeated queries in memory, and High-Performance Order Storage moves orders out of the generic posts table into dedicated tables. The WP Pro plan sets up object caching and the cart and checkout exclusions for you, which is the minimum a shop needs to stay quick.
If you have done all of this and the admin area is still sluggish, checkout slows down during campaigns, or TTFB swings with the time of day, the bottleneck is no longer your configuration but shared CPU. That is the point to move from WordPress hosting to premium hosting, where CPU cores and memory are reserved for your site alone, backups run hourly and tickets go straight to a senior engineer. Premium S starts at €24.99 a month. At WebHostFlow the upgrade happens in place — same account, same paths, same IP address — so you can measure again the next day and see whether the numbers moved.