Why Your New VPS Is Slower Than Shared Hosting (And the Exact 5-Minute Fix)

If your VPS is slower than shared hosting right after migration, the server is probably not weaker. The old shared host likely had caching, OPcache, PHP workers, object cache, web server rules, and database defaults already tuned. Your new VPS may have better CPU, more RAM, SSD storage, and full root access, but none of that matters if PHP-FPM has five workers, OPcache is missing, Redis is not connected, NGINX is not caching, MariaDB is running defaults, or the site is swapping. The first fix is a five-minute triage: check PHP version, OPcache, RAM, PHP-FPM workers, Redis, page cache, and database state before blaming the VPS.

This is a panic-search problem. You moved from shared hosting to a VPS because you expected more speed. Now the site feels worse, the client is angry, or the store is losing orders. The ugly truth is that a fresh unmanaged VPS can absolutely perform worse than quality shared hosting until someone configures the stack properly. A VPS gives you control. It does not automatically give you tuning.

If you want the server layer handled by people who tune production stacks daily, start with ServerSpan VPS hosting or hand the problem to ServerSpan Linux Administration. If you are fixing it yourself, start with the checklist below.

The 5-minute VPS performance triage

Run these checks before changing random settings. They tell you whether the problem is PHP, memory, cache, database, or web server configuration.

php -v
php -m | sort | egrep 'opcache|redis|mysqli|curl|mbstring|xml|zip|imagick|gd'
php -i | egrep 'opcache.enable|opcache.memory_consumption|opcache.max_accelerated_files|opcache.validate_timestamps'
free -h
df -h
uptime
systemctl status php*-fpm --no-pager
systemctl status nginx apache2 mariadb mysql redis-server --no-pager 2>/dev/null
redis-cli ping 2>/dev/null
mysqladmin proc stat 2>/dev/null

The output usually exposes the problem fast:

• Old PHP version: you migrated into slower or unsupported runtime behavior.
• OPcache missing or disabled: PHP recompiles scripts instead of using cached bytecode.
• Low free memory or swap in use: the VPS is under-sized or misconfigured.
• PHP-FPM stopped or under-provisioned: requests queue or fail.
• Redis not responding: persistent object cache is not active.
• MariaDB overloaded: database queries are the bottleneck.
• No page cache: every anonymous visitor hits PHP and MySQL.

Do not skip straight to buying a bigger VPS. A larger untuned VPS is still untuned. In our experience handling “my server is slow” tickets, the fastest wins usually come from OPcache, PHP-FPM worker sizing, Redis object cache, NGINX FastCGI cache, and stopping swap pressure.

Fix 1: make sure PHP is current and OPcache is enabled

Start with PHP. WordPress performance depends heavily on the PHP runtime. The official WordPress performance handbook explicitly points to current software versions, PHP optimization, OPcache, web server caching, and database optimization as major performance levers. PHP’s official supported-version table shows PHP 8.2, 8.3, 8.4, and 8.5 as supported branches as of May 2026, with older branches out of the safe path.

php -v
php -i | grep 'opcache.enable'
php -i | grep 'opcache.memory_consumption'
php -i | grep 'opcache.max_accelerated_files'

If OPcache is disabled, enable it. PHP’s official OPcache documentation lists opcache.enable as enabled by default and opcache.memory_consumption as 128 MB by default, but real VPS images and panel builds vary. Do not assume. Check.

For a normal WordPress or WooCommerce VPS, start with this:

opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=10000
opcache.validate_timestamps=1
opcache.revalidate_freq=2

On Debian or Ubuntu with PHP-FPM, the file is usually under a path like:

/etc/php/8.3/fpm/conf.d/10-opcache.ini
/etc/php/8.3/fpm/php.ini

Restart PHP-FPM after changes:

systemctl restart php8.3-fpm

If you are using DirectAdmin or cPanel on the VPS, select the PHP version from the panel first, then verify from the shell. Panel selection and CLI PHP are not always the same binary. That mismatch causes lazy debugging and wrong conclusions.

Fix 2: tune PHP-FPM workers instead of starving the site

A new VPS often has conservative PHP-FPM defaults. That is safe, but it can be slow. If pm.max_children is too low, visitors wait in line even while the VPS still has free CPU. If it is too high, the VPS runs out of RAM and Linux starts killing processes or swapping.

Find the active pool:

grep -R "pm.max_children" /etc/php/*/fpm/pool.d/

Measure average PHP memory during real traffic:

ps -ylC php-fpm8.3 --sort:rss
ps -o rss= -C php-fpm8.3 | awk '{sum+=$1; n++} END {if (n>0) print "avg MB:", sum/n/1024}'

Use this rough calculation:

pm.max_children = RAM available for PHP / average PHP-FPM process size

Example: a 4 GB VPS with 1.5 GB reserved for OS, MariaDB, Redis, and buffers leaves about 2.5 GB for PHP. If each PHP-FPM child uses about 70 MB, a reasonable pm.max_children is around 35.

pm = dynamic
pm.max_children = 35
pm.start_servers = 6
pm.min_spare_servers = 4
pm.max_spare_servers = 10
pm.max_requests = 500

Restart PHP-FPM after editing:

systemctl restart php8.3-fpm

Operational insight: on a small WooCommerce VPS, you usually run out of PHP workers before you run out of raw CPU. People look at a low load average and assume the server is fine. Meanwhile, PHP-FPM has no free children and requests are waiting.

Fix 3: add Redis object cache if the old host had it

Many quality shared hosts quietly include object caching, or they run tuned database layers behind the scenes. Your VPS may not. WordPress explains that persistent object caching speeds page loads by saving trips to the database, and without it the web server repeatedly reads options and other data from MySQL or MariaDB on every page view.

Check Redis:

redis-cli ping

If Redis is running, the expected response is:

PONG

Install Redis if missing:

apt update
apt install redis-server php-redis
systemctl enable --now redis-server
systemctl restart php8.3-fpm

Then install a WordPress Redis object cache plugin and enable it from WordPress admin or WP-CLI. The server service alone is not enough. WordPress must actually use Redis.

wp plugin install redis-cache --activate
wp redis enable
wp redis status

If you do not have WP-CLI, enable it through the plugin interface. Then check the plugin status. A Redis service that is running but not connected to WordPress gives you confidence without performance.

Fix 4: restore page cache or FastCGI cache

This is the most common reason a shared host feels faster than a new VPS. The old host may have had server-level page cache, LiteSpeed Cache, NGINX FastCGI cache, Varnish, or a tuned caching plugin. The new VPS may be serving every anonymous page request through PHP and MariaDB.

WordPress states that caching plugins can serve static files and reduce processing load, and that server-side caching can serve pre-built pages without executing the full web server, PHP, and WordPress stack. NGINX’s own FastCGI module documents fastcgi_cache, with caching off by default unless configured.

Check whether NGINX is exposing cache status. Some stacks add a header like this:

curl -I https://example.com | egrep -i 'cache|x-cache|fastcgi'

If there is no page cache, install a proper WordPress page cache plugin or configure NGINX FastCGI cache. For NGINX, a basic cache zone begins like this:

fastcgi_cache_path /var/cache/nginx/fastcgi levels=1:2 keys_zone=WORDPRESS:100m inactive=60m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";

Then inside the PHP location, apply cache carefully:

fastcgi_cache WORDPRESS;
fastcgi_cache_valid 200 301 302 60m;
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;
add_header X-FastCGI-Cache $upstream_cache_status always;

Do not blindly cache WooCommerce cart, checkout, account pages, logged-in users, or requests with session cookies. A bad cache rule can leak user-specific content. A missing cache rule makes the VPS slow. The correct rule sits between those two mistakes.

Fix 5: check MariaDB before blaming the web server

A WordPress site can look like a PHP problem when MariaDB is the bottleneck. After migration, database defaults may be too small, indexes may be stale, plugins may run heavy queries, or the database may be competing with PHP for RAM.

Start with:

mysqladmin proc stat
mysqladmin extended-status | egrep 'Threads_connected|Threads_running|Slow_queries|Questions|Queries'
systemctl status mariadb --no-pager

MySQL documents mysqladmin as a client for administrative operations, including checking server status, showing active threads, and displaying a short status message. Use it because it gives fast signal during panic.

If you see many long-running queries, enable the slow query log temporarily:

mysql -e "SET GLOBAL slow_query_log = 'ON';"
mysql -e "SET GLOBAL long_query_time = 1;"

Then watch the slow log path configured by your MariaDB package. On Debian-based systems, start by checking:

grep -R slow_query_log /etc/mysql/ /etc/my.cnf* 2>/dev/null
tail -f /var/log/mysql/mariadb-slow.log 2>/dev/null

If the slow log fills immediately, your VPS is not “slow” in general. Your database workload is slow. Redis object cache, plugin cleanup, query optimization, and proper MariaDB buffer sizing will do more than buying more vCPU.

Memory and swap: the silent VPS killer

Shared hosting hides memory management. A VPS exposes it. If the new VPS has 1 GB RAM and you installed NGINX, PHP-FPM, MariaDB, Redis, malware scanning, backups, monitoring, and a control panel, you may be out of memory before real traffic arrives.

free -h
swapon --show
vmstat 1 5
dmesg -T | egrep -i 'killed process|out of memory|oom'

If swap is active under normal traffic, the site will feel randomly slow. If the OOM killer appears in dmesg, Linux is killing processes because memory is exhausted. That is not a caching issue. That is sizing or configuration.

For small WordPress, 2 GB RAM is a more realistic starting point than 512 MB if the server also runs MariaDB and Redis. For WooCommerce, 4 GB is a healthier floor. On ServerSpan, that usually means vm.Ready for small production sites and vm.Steady for WooCommerce, heavier WordPress, Redis, backups, and monitoring. Prices exclude VAT.

Why the old shared host felt faster

Good shared hosting is not just a directory on a server. It often includes tuned PHP, OPcache, shared web server cache, static file handling, database tuning, malware rules, backup routines, and a control panel that hides the complexity. You moved away from platform limits, but you also moved away from platform tuning.

That is why “better specs” can lose to “better configuration.” A 4 vCPU VPS with no cache can lose to a shared host with page cache. A VPS with 6 GB RAM can feel slow if PHP-FPM has five workers. NVMe storage does not compensate for a database query that runs 400 times per page. Root access does not make OPcache enable itself.

The real upgrade is not shared hosting to VPS. The real upgrade is shared hosting to a correctly tuned VPS.

The exact 5-minute fix, in order

If you need the shortest possible action list, do this:

1. Check PHP version and move to PHP 8.3 or 8.4 if the site supports it.
2. Enable OPcache and raise opcache.memory_consumption to 256 MB.
3. Check pm.max_children and increase it based on real RAM and process size.
4. Install and connect Redis object cache for WordPress.
5. Enable page cache through WordPress cache plugin or NGINX FastCGI cache.
6. Check mysqladmin proc stat for database pressure.
7. Check free -h, swap, and OOM logs before assuming you need more CPU.

That is more than one command, but it is still the fastest honest path. The dishonest version is “upgrade RAM” or “install a cache plugin” without diagnosis. That can help, but it also wastes time when the real problem is PHP workers, OPcache, Redis, database queries, or swap.

When the fix is not 5 minutes

Some problems are not quick configuration misses. These need deeper work:

• a bloated WordPress theme that loads hundreds of assets
• too many plugins creating autoloaded options
• WooCommerce tables with missing indexes or huge order metadata
• external API calls blocking page render
• malware injecting slow code
• backup jobs running during peak traffic
• image optimization or thumbnail regeneration saturating CPU
• wrong web server architecture after migration

This is where professional help is cheaper than guessing. If the site matters, use Linux server administration instead of turning production into a lab.

Shared hosting might still be the right answer

Be honest about your situation. If you run a small brochure site, a portfolio, or a quiet blog, a quality web hosting plan can be a better fit than an unmanaged VPS. The panel, mail, SSL, backups, PHP, and caching are already packaged for you.

A VPS makes sense when you need control, scaling, Docker, custom software, isolated staging, Redis, worker queues, WooCommerce capacity, or root-level troubleshooting. If you do not want to manage those pieces, choose managed VPS or stay on good shared hosting. Do not buy infrastructure you are not prepared to operate.

Recommended ServerSpan path after a slow VPS migration

If you just migrated and the VPS is slower than shared hosting, do not panic-buy the largest plan. First, identify whether the bottleneck is cache, PHP workers, database, memory, or disk. Then choose the right path:

• Small WordPress site: shared hosting or vm.Ready if you need root access.
• Business WordPress site: vm.Ready with proper PHP-FPM, OPcache, Redis, and backups.
• WooCommerce or heavy WordPress: vm.Steady as the healthier floor.
• Multiple sites, staging, monitoring, and background workers: vm.Steady or vm.Go.
• No sysadmin time: managed VPS plus Linux Administration support.

ServerSpan VPS plans include KVM options with full root access, dedicated resources, SSD storage, IPv4, IPv6, DDoS mitigation, and data center choices in the USA, Canada, and Germany. The hardware is not the hard part. The hard part is making the stack behave correctly under real traffic.

Related reading before you change anything else

If you are deciding whether the VPS was the right move, read Shared Hosting vs VPS: Which One Do You Actually Need in 2026?. If you want the support-side view of vague performance complaints, read The Reality of "My Server Is Slow" Tickets. If the problem is specifically WordPress behind NGINX and PHP-FPM, read WordPress 502 Bad Gateway in 2026.

The practical answer

Your new VPS is probably slower than shared hosting because the shared host had optimized defaults and your VPS has raw resources without tuning. Fix the stack in this order: PHP version, OPcache, PHP-FPM workers, Redis object cache, page cache, MariaDB state, memory, and swap. A VPS is not automatically faster. A tuned VPS is faster, more controllable, and easier to scale.

If you want that outcome without becoming the sysadmin, start with managed VPS hosting from ServerSpan and use Linux Administration when the problem needs hands-on tuning. The fix is not magic. It is configuration.