You've installed a caching plugin. You've compressed your images. You've deleted plugins you don't use. Your site is still slow. The reason is almost certainly your hosting. Here's how to diagnose what's actually going on and fix it properly, starting with the measurement that matters most.
Run your site through Google PageSpeed Insights or WebPageTest and look at your TTFB figure. This is how long the server takes to send the first byte of data back to the browser after receiving the request. A good TTFB is under 200ms. Anything over 600ms is a server problem, not a plugin or front-end problem.
No amount of minifying JavaScript or compressing CSS fixes a slow server. The server responds before the browser can even start downloading those assets. If TTFB is the problem, front-end optimisation is cosmetic at best. Solve the server first.
In WebPageTest, look specifically at the Waterfall view. The first bar, the initial HTML document request, shows your raw TTFB. If that bar extends past 1 second before the download portion even starts, you have a server response problem.
Cheap shared hosting puts hundreds of sites on the same physical server. When your neighbours get traffic, your CPU allocation gets squeezed. During peak hours on a budget shared host, you may be one of 500+ sites competing for the same pool of processing power. You have no control over this and no visibility into it from inside your account.
The tell-tale sign is a TTFB that varies wildly throughout the day, fast at 3am, sluggish at midday. Your site hasn't changed; the server load has. If this describes your situation, you need better hosting infrastructure, not better plugins.
If your host runs Apache with no caching layer, every page request fires PHP and hits the database. On a quiet site this is manageable, 200ms or so per request. Under real traffic it falls apart fast, because every concurrent visitor is running a full PHP process.
A PHP-based caching plugin like WP Rocket or W3 Total Cache generates static HTML files and serves them on repeat visits, but PHP still has to load and bootstrap to decide whether to serve the cache. That overhead is typically 100–200ms per request even with caching active.
Server-level caching like LiteSpeed Cache works differently. The cached response is returned by the web server before PHP is invoked at all. TTFB drops to 30–80ms on a warm cache. This is the mechanism that makes LiteSpeed hosts so much faster in benchmarks, not marketing, but a fundamentally different request path.
PHP 8.x is significantly faster than PHP 7.x for WordPress workloads. Benchmarks consistently show PHP 8.2 executing WordPress 30–50% faster than PHP 7.4 on the same hardware. If your host is running PHP 7.4 or older by default, you're leaving substantial performance on the table. Check your PHP version in your hosting control panel and update to 8.2 or the latest stable version.
Before updating, check that your active plugins and theme declare compatibility with PHP 8.x. Most major plugins do, but older or abandoned plugins sometimes don't. The easiest way to check is to update on a staging site first and look for errors before touching production.
If your server is physically located far from your visitors, content takes longer to travel. A UK-based server sending assets to a visitor in Australia adds 200–300ms of round-trip latency before a single byte loads in their browser, and that latency stacks for every resource the page requests.
A CDN caches static assets (images, CSS, JavaScript, fonts) at edge locations physically closer to each visitor. For a UK site, Cloudflare's free tier has over 300 edge locations globally. Connecting your WordPress site to Cloudflare via your DNS settings takes under 10 minutes and typically reduces load times for international visitors by 30–60%.
This is the one area where plugins genuinely help regardless of your hosting quality. A hero image uploaded at 4000px wide and 3MB in size will slow down any page, on any server. Images should be resized to the largest dimensions actually displayed on the page, compressed, and ideally served in WebP format (which is 25–35% smaller than JPEG at equivalent quality).
Lazy loading prevents images below the fold from loading until the user scrolls to them, improving initial page load and LCP scores. The LiteSpeed Cache plugin handles image optimisation, WebP conversion, and lazy loading in one place. Imagify and ShortPixel are strong alternatives if you're not on LiteSpeed hosting.
Too many plugins doing overlapping jobs, multiple security plugins, several social sharing plugins, redundant analytics scripts, add HTTP requests and execution time to every page load. Audit your plugins annually: deactivate anything you don't recognise or actively use, and check whether your host already provides something a plugin duplicates (backup plugins are a common example on hosts that already take daily backups).
Render-blocking scripts, JavaScript or CSS that loads in the <head> of the page before content, delay when the browser can start displaying anything. In PageSpeed Insights, look for "Eliminate render-blocking resources" suggestions. Moving scripts to load asynchronously or deferring non-critical JavaScript often improves LCP by 300–600ms.
If your TTFB is over 400ms and you're on a budget shared plan, you're at the ceiling of what optimisation can achieve. The correct order of operations is: move to a host running LiteSpeed with server-level caching, update to PHP 8.2, enable Cloudflare, then optimise images and audit plugins. Done in that sequence, most WordPress sites drop from 4–6 second load times to under 1.5 seconds. Doing steps 3 and 4 without steps 1 and 2 produces marginal gains that don't move the needle on user experience.
HostBible runs LiteSpeed with LSCache active, PHP 8.2 as default, and Cloudflare-compatible infrastructure on every plan. We'll migrate your site for free.
View Hosting Plans