Why Is My Website So Slow? 10 Hosting Causes and How to Fix Each

When a slow site traces back to hosting, it almost always shows up as a slow Time to First Byte (TTFB): the delay between the browser asking for a page and the server sending the first byte of it back. Google's guidance treats TTFB under roughly 800 milliseconds (measured at the 75th percentile of real visits) as fine, 800 to 1,800 as needing work, and over 1,800 as poor. If your TTFB sits above that line while your images, fonts and scripts are already a sensible size, the server is your bottleneck, not your front end.

The usual hosting causes, roughly in the order they turn out to be the real problem: too many sites crammed onto your shared server, your plan's CPU and process limits throttling you, an outdated PHP version, no full-page cache running on the server, dynamic pages with no object cache, a database on slow or oversubscribed disk, a server in the wrong part of the world with no CDN in front of it, outdated web server software, too little memory so the server swaps to disk, and slow DNS or backup jobs colliding with your busiest hours.

Most of these are fixed with a configuration change, a caching layer or a plan upgrade, not a rebuild. A few mean the host itself is the ceiling and the only fix is to leave. This guide covers how to tell which one you are looking at, and what each fix actually involves.

Check that it is actually the host first

About half of "my site is slow" complaints are the owner's own plugins and images, not the server. Two checks take three minutes and save you from fixing the wrong thing.

Run one page through a test that splits server time from download time. WebPageTest, GTmetrix or your browser's own Network panel (press F12, open Network, reload, hover over the first request) all show "waiting for server response" separately from the time spent transferring HTML, images and scripts. Load the page twice so the second run benefits from any caching. If the second load still waits 600 milliseconds or more before the first byte arrives, that wait is the server.

Compare the public site with wp-admin (or your CMS dashboard). The admin area is deliberately never full-page cached, so it is the closest thing you have to a raw view of server and database performance. A quick homepage next to a crawling dashboard points straight at hosting rather than your theme.

Check where the test ran from. A test server in the same data centre as your host reports a flattering TTFB. If your visitors are in the UK, test from London. A number that looks fine from Virginia and terrible from London is a geography problem, covered in cause 7.

If TTFB is low from every location and the page is still slow, the work is in your front end: image weight, render-blocking scripts, plugin bloat. Nothing on the hosting side will move the needle much. If TTFB is high, this table points you at the likely cause.

1. Too many sites are packed onto your shared server

On shared hosting your site runs alongside dozens or hundreds of others on one physical machine, sharing its CPU, memory and disk. Hosts deliberately sell more capacity than the hardware physically has, betting that most sites are idle most of the time. Industry discussion and host disclosures put a sensible density at roughly 80 to 120 active WordPress sites per modern server; the cheapest plans can land 300 to 500 accounts on the same box. When a handful of those neighbours get busy at once, everyone else queues behind them. This is the "noisy neighbour" problem, and on budget hosting it is the single most common reason a site feels slow for no reason you can see.

How it shows up: TTFB that is fine overnight and poor during business hours. Speed test results that swing wildly from one minute to the next. A server load average, visible in cPanel under "Server Information", sitting above the number of CPU cores.

Confirm it: run the same TTFB test every hour for a day. A clean 200ms at 4am and 1,500ms at 2pm, with your own traffic flat throughout, is the noisy-neighbour signature.

Fix it:

• Ask support to move your account to a less loaded server. This is a routine request and often buys months of relief.
• Move to a plan with resources allocated to you rather than shared: a proper VPS, or "cloud" hosting where CPU and RAM are reserved.
• If you are already paying mid-range shared prices and still getting contended, the host is overselling harder than the price suggests. Treat that as a reason to switch.

A managed VPS or cloud plan with genuinely reserved resources typically runs £15 to £40 a month, against £3 to £8 for budget shared.

2. You are constantly hitting your plan's resource limits

Most cPanel shared hosts run CloudLinux, which places every account in a cage called an LVE (Lightweight Virtual Environment) with hard caps: a CPU percentage, a memory ceiling, an I/O rate, and a limit on entry processes (EP), meaning how many PHP requests you can run at the same time. Per CloudLinux's own documentation, hitting a limit does not kill the account, it throttles it: requests slow down or queue, and when CPU or process use stays pegged, waiting visitors get a "508 Resource Limit Is Reached" page. The entry-process cap is usually the one that bites first, and on cheap plans it is often set to 20 or fewer. A single slow plugin holding a three-second database call open can block every other visitor for that whole time.

How it shows up: intermittent 508 or 503 errors under mild traffic. The site "cannot handle" 15 concurrent visitors. Fine for one person, collapsing for a small crowd.

Confirm it: in cPanel, open "Resource Usage" or "CPU and Concurrent Connection Usage". It shows which specific limit you have been hitting and how often. This matters, because the fix for a CPU limit (faster code, caching) is nothing like the fix for an entry-process limit (fewer, quicker requests or a higher cap). Raising the wrong one does nothing.

Fix it:

• Add a full-page cache (cause 4) so most visits never start a PHP process at all. This is the biggest single lever on the entry-process limit.
• Upgrade PHP (cause 3) to cut CPU time per request.
• Find the slow code: install Query Monitor on WordPress and look for slow queries or slow external API calls on your key pages.
• If your usage is legitimately high, buy a plan with higher limits or move to a VPS where you set them yourself.

Usually this is a one-tier plan upgrade at £5 to £15 a month, or free if caching alone solves it.

3. Your site is running an outdated version of PHP

PHP is the language most content management systems run on, and every release since 7.4 has done the same work faster. Independent WordPress benchmarks from Kinsta and Tideways show throughput improving across PHP 8.0, 8.1, 8.2, 8.3 and 8.4, on the order of 10 per cent or more in requests per second over 7.4, with opcache and JIT improvements doing most of the lifting. Slower PHP means more CPU time per request, which means higher TTFB and a greater chance of hitting the limits in cause 2. PHP 7.4 also stopped receiving security patches in November 2022, so an old version is a safety problem as well as a speed one.

How it shows up: a flat, all-day TTFB penalty of 100 to 300 milliseconds that no amount of front-end work removes.

Confirm it: in cPanel look for "Select PHP Version" or "MultiPHP Manager". Anything below 8.1 is leaving speed on the table; anything below 7.4 is unsupported.

Fix it: switch to PHP 8.2 or 8.3 in the hosting panel. Test a staging copy first, because a very old plugin or a hand-built theme can break. Sites that are reasonably maintained upgrade with no visible change except lower TTFB. Turn on OPcache too if your host exposes the toggle; it keeps compiled PHP in memory instead of recompiling it on every request.

This fix is free.

4. There is no full-page cache running on the server

Without caching, every single visit makes your server run PHP, query the database 30 to 60 times, build the HTML and then send it. A full-page cache stores the finished HTML the first time and serves that copy straight from memory or disk to the next visitor, skipping PHP and the database entirely. Cloudways' published testing showed TTFB on a WordPress page dropping from 759ms to 141ms once server-level caching (Varnish) was switched on, and a 50 to 70 per cent TTFB reduction is a fair general expectation once a page cache is in place.

How it shows up: consistent 600ms to 1,500ms TTFB on content that does not change between visitors, such as a blog post or a static homepage.

Confirm it: load a page, then view the response headers (browser Network panel, click the document request, open the Headers tab). Look for x-cache, x-litespeed-cache, cf-cache-status or age. If there is no cache header, or it always says MISS, nothing is caching the page.

Fix it:

• On LiteSpeed hosts: install the free LiteSpeed Cache plugin and enable it. It talks directly to the server cache.
• On NGINX hosts: ask whether FastCGI caching is available. Many managed hosts have a toggle for it.
• On Apache-only budget hosts: install WP Rocket, W3 Total Cache or the free WP Super Cache. These cache at the PHP level, which is less effective than a server cache but still a large win.
• Cloudflare's free plan can cache your HTML at its edge with a "Cache Everything" page rule, though this needs care on sites with logged-in areas or carts.

Cost ranges from free to about £50 a year for a premium plugin.

5. Dynamic and logged-in pages have no object cache

A full-page cache is bypassed for anyone who is logged in, has items in a cart or triggers personalised content, which describes most of the important traffic on a membership site, a forum or a WooCommerce store. Those requests still hit the database on every load. A persistent object cache (Redis or Memcached) keeps the results of repeated database queries in memory between requests. A database query takes single-digit to tens of milliseconds; a Redis lookup takes a fraction of one. Kinsta and others report object caching removing a large share of repeat queries on a typical WordPress load, which shows up directly in TTFB for exactly the pages a page cache cannot touch.

How it shows up: the logged-out homepage loads in 300ms, while the same site's account page or cart takes 1.5 seconds. WooCommerce "cart" and "checkout" are consistently slow.

Confirm it: Query Monitor shows the query count and total query time per page. Hundreds of queries, or 200ms and up spent in the database on a logged-in page, means an object cache would help.

Fix it: check whether your host offers Redis. Many managed WordPress hosts and mid-tier cPanel hosts do. If so, install the free Redis Object Cache plugin, or enable Redis in LiteSpeed Cache, and confirm it reports as connected. If your host has neither Redis nor Memcached, that absence is itself a reason to consider moving a database-heavy site. One caveat from doing this on real sites: enabling Redis alongside a badly written plugin that ignores the cache API gives you very little, so measure TTFB before and after rather than assuming.

Free where the host provides Redis; a paid plan feature otherwise.

6. The database is on slow or oversubscribed storage

A single WordPress page render can fire 40 to 60 database queries, and every one is a read, sometimes a write, against disk. On budget hosts the MySQL or MariaDB server is shared across many accounts and may still sit on SATA SSDs, or on network storage. NVMe drives deliver roughly 5 to 10 times the random IOPS of SATA SSDs and cut access latency from around 100 to 200 microseconds down to under 20, per hosting benchmarks from MassiveGRID and others. Multiplied across 50 queries a page and dozens of concurrent visitors, that gap becomes visible in TTFB.

How it shows up: TTFB that gets dramatically worse under concurrency while a single visit is only mildly slow. A sluggish wp-admin. Query Monitor showing individual simple queries taking 20ms and up when they should be well under a millisecond.

Confirm it: ask the host two questions: what storage type the database server uses, and whether your database sits on the same node as your site or on a shared cluster. Slow simple queries in Query Monitor, with an object cache already in place, point at the disk or a contended database host.

Fix it:

• Move to a host or plan that specifies NVMe storage. Many now do. If yours will not confirm the storage type, treat that as the answer.
• Keep the database lean: clear spam, trim post revisions, remove orphaned metadata, and run a tool like WP-Optimize occasionally. A smaller database fits in memory and reads faster.
• Make sure tables use the InnoDB engine rather than the older MyISAM, which locks the entire table on every write.

NVMe plans typically cost 10 to 30 per cent more than their SATA equivalents.

7. Your server is in the wrong part of the world, with no CDN in front of it

Data has to physically travel between the visitor and your server, and every round trip (the DNS lookup, the TLS handshake, then the request itself) pays that distance in time. A visitor in London hitting a server in London might see 20ms of network latency; the same visitor hitting a US East server pays around 80 to 100ms per round trip, and a page needs several round trips before it renders. Testing referenced by Kinsta and others shows visitors close to the origin getting two to four times lower TTFB than distant ones. A CDN fixes this by keeping copies of your content on servers near the visitor, so most requests never cross an ocean.

How it shows up: TTFB and load time that vary sharply by visitor location. Analytics showing high bounce and low pages per session from one particular country.

Confirm it: run your page through a multi-location speed test. WebPageTest lets you pick the test city. If London reports 300ms and Sydney reports two seconds, it is distance.

Fix it:

• First, host in the region most of your visitors are in. A UK audience belongs on a UK or nearby EU data centre. Many hosts let you choose the region at signup but not afterwards, which can mean a migration.
• Put a CDN in front. Cloudflare's free tier and Bunny CDN (from about a pound a month plus usage) both cache static files globally, and can cache HTML too with the right rules.
• For a genuinely global audience, choose a host with multiple regions or edge caching built in.

Cost runs from free (Cloudflare) to a few pounds a month.

8. The web server software itself is outdated or stripped down

The software that accepts connections and hands work to PHP matters more than most site owners realise. Old Apache with mod_php spawns a full process per request and holds its memory for the whole request. NGINX and LiteSpeed use an event-driven model that handles far more concurrent connections on the same hardware, and LiteSpeed's LSCache serves cached pages without waking PHP at all. Independent benchmarks repeatedly show LiteSpeed with LSCache, or NGINX with FastCGI caching properly tuned, sustaining several times the requests per second of stock Apache under load.

The transfer protocol is part of the same picture. HTTP/2 and HTTP/3 send many files down one connection instead of queuing them, so a host still on HTTP/1.1 adds delay to every page with more than a handful of assets. Compression matters too: Brotli shrinks HTML, CSS and JavaScript roughly 15 to 20 per cent smaller than the older gzip, per Akamai and DebugBear testing, and both are a server setting. If response headers show no content-encoding, nothing is being compressed and every text file is leaving the server at full size.

How it shows up: the site copes with one visitor but stumbles under mild concurrency. Waterfall charts showing assets loading in strict sequence rather than in parallel, which is an HTTP/1.1 tell.

Confirm it: the browser Network panel shows the protocol per request once you add the "Protocol" column. It will read h2, h3 or http/1.1. The response server header often names the web server software, or you can ask the host directly.

Fix it: this one is largely the host's to make, but you can:

• Choose a LiteSpeed or NGINX-based host when you next move. Many good-value hosts now run LiteSpeed specifically for LSCache.
• Confirm HTTP/2 or HTTP/3 is enabled. On most modern hosts it comes on automatically with HTTPS, and Cloudflare adds HTTP/3 in front regardless of what your origin runs.
• If you run your own VPS, replacing Apache with NGINX or OpenLiteSpeed is a project, but a worthwhile one.

Free if it is a host toggle; otherwise a factor in choosing your next host.

9. There is not enough memory, so the server is swapping to disk

When a server runs out of physical RAM, it moves memory pages onto disk (swap) to cope. Disk is orders of magnitude slower than RAM, so once a server is swapping heavily, everything on it slows down together and often does not recover until something restarts. On an undersized VPS, say 1GB of RAM trying to run WordPress plus MySQL plus a mail server, this happens under quite ordinary load. On shared hosting it shows as the whole node degrading at once.

A related trap: PHP-FPM has a max_children setting that caps how many PHP workers can run at the same time. Hit it and new requests queue or receive a 502 or 503, and the common default of 5 is far too low for a real site, per guidance from Liquid Web and others.

How it shows up: the site was fine, had a busy hour, and has been slow ever since with no configuration change. Everything is slow at once, not one specific page. If you have SSH access, top shows high load and almost no free memory.

Confirm it: on a VPS, free -m and top show memory and swap use. On shared hosting this is the host's to diagnose, but a support ticket asking "is the node swapping?" during a slow spell is a fair question.

Fix it:

• Right-size the plan. 2GB of RAM is a sensible floor for WordPress plus its database on a VPS, and 4GB once there is real traffic or WooCommerce involved.
• Add a page cache and an object cache so fewer PHP workers are needed at once.
• Raise max_children only if you have the RAM to back it, since each worker uses 30 to 80MB. Otherwise you just trade queueing for swapping.
• If a budget VPS keeps hitting its ceiling, the plan is simply too small for the job.

Each step up in RAM is usually £5 to £15 a month.

10. Slow DNS, and background jobs colliding with your traffic

Two smaller causes that belong together because both come down to timing.

DNS resolution. Before a browser can connect at all, it looks up your domain name. A typical lookup takes 20 to 120 milliseconds, but a slow or overloaded nameserver can push that far higher; Cloudflare has published cases of DNS responses over 700ms sitting behind poor TTFB numbers. Budget registrars often run mediocre DNS by default.

• Confirm: WebPageTest breaks out "DNS lookup" as its own bar in the waterfall. DNSPerf publishes provider rankings.
• Fix: move your domain's DNS to a fast anycast provider. Cloudflare's is free and sits consistently near the top for global response time. This is a nameserver change at your registrar, not a hosting migration, and it is reversible.

Backups, cron and scans running during your peak. Budget hosts often schedule the nightly account backup for a fixed server-time slot that may fall in your afternoon. The backup reads your entire account off disk, spiking I/O for everyone on the node. WordPress's own wp-cron fires on visits and can pile up overdue tasks. Security plugins running full-site file scans do the same to CPU and disk.

• Confirm: does the slow period recur at the same clock time every day? Ask the host when node backups run.
• Fix: ask whether the backup time can be changed, or move to a host that uses snapshot backups, which are near-instant and low I/O. Replace wp-cron with a real server cron job (set DISABLE_WP_CRON to true and add a system cron every five minutes). Schedule security scans for genuine low-traffic hours in the plugin settings.

Both fixes are free.

The ten at a glance

When no setting will fix it

Some of the ten are host problems you cannot configure your way out of: chronic overselling, no NVMe option, no Redis, US-only data centres for a UK audience, Apache-only with tight limits. If you have worked through caching, PHP and plan size and TTFB is still above a second on a simple cached page, the host is the ceiling.

What to look for in the next one:

One practical note from doing these migrations: test TTFB from a temporary URL on the new host before you point DNS across, using the same page and the same test location as your current baseline. If the new host is not clearly faster on a like-for-like page, the move is not worth the risk, and the real problem may be inside your site after all.

Related guides

• Why You Still See the Old Site After Changing Nameservers: what to expect during the DNS switch if a hosting move is where this ends up.
• Server DNS Address Could Not Be Found: What It Means and How to Fix It: for when the site is not slow but unreachable, which is a DNS problem rather than a hosting one.
• Domain Email Stopped Working After Website Migration: the companion problem to a host move, and how to keep mail flowing through it.
• Not Receiving Emails on Your Domain? An MX-Record Checklist That Finds the Cause: the same record-by-record thinking applied to email delivery.