Support 24/7
Client areaGet started
Shared hostingManaged WordPressReseller hostingOpenClaw hostingVPS hostingDedicated serversManaged serversAbout usHow we compareRegionsKnowledge baseSupportDomainsSSLBlogClient area
WordPress
Blog / WordPress

Why is my WordPress site slow on shared hosting? Check these five things first

“The host is slow” is the usual diagnosis and it is usually wrong. On nine sites out of ten the server is fine and something on top of it is doing far more work than it needs to. Here is the order we check, which is also roughly the order of how often each one turns out to be the culprit. 1. CacheIs anything cached at all? Check the response headers in a private window. 2. DatabaseHow long do the queries take, and how many are there? 3. PHP versionThe version the site actually runs, not the

N
Nikolay · Team lead, SRE/DevOps
September 18, 2026 · 3 min read

“The host is slow” is the usual diagnosis and it is usually wrong. On nine sites out of ten the server is fine and something on top of it is doing far more work than it needs to. Here is the order we check, which is also roughly the order of how often each one turns out to be the culprit.

  1. CacheIs anything cached at all? Check the response headers in a private window.
  2. DatabaseHow long do the queries take, and how many are there?
  3. PHP versionThe version the site actually runs, not the one the panel advertises.
  4. PluginsWhich one is firing the slow queries and the slow hooks.
  5. NeighboursOnly now suspect shared CPU and disk.

Check in this order. It is also roughly the order of how often each one turns out to be the culprit — the neighbours are last for a reason.

1. Is anything cached at all?

Open the site in a private window and look at the response headers:

curl -sI https://example.com/ | grep -iE 'x-litespeed-cache|cf-cache-status|age|cache-control'

x-litespeed-cache: hit means the page was served from cache and never touched PHP. A miss on every request means every visitor is making WordPress rebuild the page from the database — usually 200–800 ms of work that could have been 5 ms.

The common causes of a permanent miss: no cache plugin, a cache plugin installed but not enabled, a cookie set on every request (many chat and consent plugins do this) which makes the page uncacheable, or WP_CACHE missing from wp-config.php. Fix caching first, because every measurement after this one changes once it is on.

2. How long does the database take?

Install Query Monitor, load the slow page as an administrator and look at two numbers: total query time and the number of queries. A reasonable page is under 100 queries and under 50 ms of database time. Hundreds of queries usually mean a plugin is asking for things in a loop; 500 ms of database time on a small site usually means a query with no index behind it.

wp db query "SHOW FULL PROCESSLIST;" --allow-root   # what is running right now
wp option get cron --format=json | head -c 400       # a cron list that never empties is a symptom

WordPress stores transients, sessions and orphaned autoloaded options in wp_options, and every page load reads all of the autoloaded ones. On a site that has had a dozen plugins come and go, that table is often tens of megabytes:

wp db query "SELECT ROUND(SUM(LENGTH(option_value))/1024/1024, 2) AS mb
             FROM wp_options WHERE autoload='yes';" --allow-root

Over about 1 MB is worth cleaning. Over 5 MB is your problem.

3. Which PHP version is it actually running?

Not the one in the panel — the one the site uses. PHP 8.3 is roughly twice as fast as 7.4 on WordPress workloads, and 7.4 has been out of security support since 2022.

wp eval 'echo PHP_VERSION;' --allow-root

If a plugin blocks the upgrade, that plugin is a liability twice over: it is holding back performance and it is unmaintained enough to break on a five-year-old runtime.

4. Find the plugin that is doing the work

Query Monitor attributes queries and slow hooks to the plugin that fired them. The usual suspects are related-posts widgets, “popular this week” counters, broken-link checkers, statistics plugins that write a row per pageview, and security plugins that scan on every request. Any of them can add 300 ms to every page while a cache is off — and the statistics ones keep doing it even when the cache is on, because they need the request to reach PHP.

Deactivate suspects one at a time on a staging copy and measure. Do not do this on the live site at 6 p.m.

5. Only now suspect the neighbours

Shared hosting means shared CPU and disk. If your site is fast at 3 a.m. and slow at midday, and you have already ruled out the first four, then you are competing for resources. The numbers that matter are the container’s CPU and I/O limits and whether you are hitting them — a decent panel shows both. Hitting your own CPU limit means the site needs a bigger plan or less work per request; a server that is busy regardless of what you do means the host oversold it.

On inSave plans each site runs in its own container with its own CPU, RAM and I/O limits, so a neighbour’s traffic cannot take your site down — and the panel shows exactly how close to those limits you are. LiteSpeed and LSCache are on every plan, which removes step 1 for most sites, and Redis object cache comes with Shared Pro and up.

The short version

Cache first, database second, PHP version third, plugins fourth, neighbours last. Four of those five are yours to fix on any host, which is why “move to a faster host” so often disappoints: the new server runs the same expensive code, just for more money.