How a Linux VPS Improves Website Performance

Quick Summary

Migrating to a Linux VPS does not automatically make a website faster. If you leave the server with its default configuration, TTFB and page generation times may barely change. Real performance improvements come from having full control over the server and being able to tune PHP-FPM, Nginx or Apache, Redis, Memcached, MySQL or MariaDB, OPcache, HTTP/2, HTTP/3, and the other components that directly affect request processing.

On a typical shared hosting platform, most of these settings are either unavailable or fixed for every customer on the server. If the default configuration is not suitable for your application, there is little you can do to change it. As a result, you end up adapting the website to the platform instead of adapting the platform to the website.

This is why moving the same project to a VPS does not necessarily produce an immediate speed boost. A server running its default Linux configuration often performs only marginally better than before. Meaningful improvements appear only after the components responsible for generating dynamic pages have been optimised. For WooCommerce, that usually means tuning PHP-FPM, enabling Redis Object Cache, and improving database performance. Moodle benefits greatly from properly configured PHP-FPM, OPcache, cron jobs, and MariaDB. Corporate portals, CRM systems, and B2B catalogues are more commonly affected by PHP worker exhaustion, inefficient SQL queries, or the absence of effective object caching.

Once these areas have been optimised, the difference is often visible straight away. In many cases, the TTFB of dynamic pages drops from around 700–1000 ms to 150–300 ms. The exact figures depend on the application, traffic levels, database structure, and code quality, but the improvement is typically the result of eliminating bottlenecks during HTML generation rather than simply adding more CPU cores or memory.

The first thing to do after provisioning a VPS is not to install every optimisation tool available, but to identify where the application is actually losing performance. Measure the TTFB of several pages, check CPU utilisation, review memory usage, assess database performance, and inspect your error logs. Only then should you begin adjusting PHP-FPM, enabling Redis, tuning Nginx, configuring OPcache, or changing cache settings. Working in this order helps you solve the real cause of slow page delivery instead of changing server settings by trial and error.

You can verify whether a VPS is capable of improving website performance in less than ten minutes. Open your browser's Developer Tools and measure the TTFB of several pages. Then connect to the server and inspect resource usage with top or htop, review memory consumption, confirm that Redis and OPcache are active, and make sure PHP-FPM is not building up request queues. If CPU utilisation remains low, sufficient memory is available, and TTFB is still high, the bottleneck is usually not the VPS itself but the software stack running on it.

This is something we regularly see when diagnosing customer servers at Era.Host. Upgrading hardware alone rarely solves performance issues if the application stack remains unchanged. In most cases, the biggest gains come from identifying where time is actually being spent and tuning the components responsible for generating each request.

The real advantage of a Linux VPS is not having more processor cores or additional RAM. Its greatest value lies in giving you complete control over the platform. Fine-tuning PHP-FPM, the web server, the database, caching, and network configuration allows you to reduce TTFB, generate pages faster, and improve overall application performance without constantly running into the limitations of a shared hosting environment.

How to Tell When Shared Hosting Has Become the Bottleneck

A website can be well optimised at the CMS level and still slow down during busy periods. You may have removed unnecessary plugins, compressed images, enabled page caching, upgraded PHP, and cleaned up the database, yet TTFB still climbs to 800–1500 ms every evening. At the same time, you begin seeing HTTP 503 errors, the admin area becomes sluggish, checkout occasionally stalls, and your hosting control panel shows repeated CPU, RAM, Entry Processes, or I/O limit violations. When that happens, the bottleneck is often no longer the website itself but the limitations of the shared hosting environment.

The first step is to measure TTFB properly. Don't test a single page once and assume the result is representative. Measure the homepage, category pages, product pages, search results, the shopping basket, user account pages, or any other dynamic content. Repeat the tests in the morning, afternoon, and evening, as shared hosting limits usually become visible during peak usage.

curl -o /dev/null -s -w \
"DNS: %{time_namelookup}\nTCP: %{time_connect}\nTLS: %{time_appconnect}\nTTFB: %{time_starttransfer}\nTotal: %{time_total}\n" \
https://example.com/

If TTFB remains around 200–300 ms in the morning but consistently rises to 800–1500 ms in the evening, the CMS is no longer the only place to investigate. Compare the results with a static asset such as an image or CSS file. If the static file starts downloading almost immediately while the HTML response is delayed, the bottleneck lies in PHP, the database, or server-side caching.

These initial measurements already reveal useful patterns. If TTFB only increases during busy periods, start by checking your CloudLinux resource limits and the number of active PHP workers. If only dynamic pages are slow while images, CSS, and JavaScript load quickly, the problem almost always involves PHP, the database, or object caching. If high TTFB coincides with HTTP 503 or 504 errors, inspect the web server logs and verify whether PHP-FPM has reached the pm.max_children limit. If performance only drops during product imports, search indexing, backups, or traffic spikes, investigate CPU usage, disk I/O, and the number of active PHP processes before looking elsewhere.

Next, review the resource statistics in your hosting control panel. If your provider uses CloudLinux, check CPU, RAM, Entry Processes, NPROC, I/O, and IOPS. Hitting a limit once is not necessarily a problem. However, if the graphs show the same limits being reached repeatedly at roughly the same time every day, your website has started competing for resources within the shared environment. At that point, new PHP requests begin waiting for available workers, read and write operations slow down, and visitors experience long page loads instead of prompt server responses.

This is particularly common with online shops. The website performs well during quieter periods, but in the evening dozens of visitors browse product pages, search the catalogue, apply filters, and complete purchases simultaneously. Overall CPU utilisation may still appear relatively low, yet every available PHP worker is already processing existing requests. It looks as though the server lacks computing power when, in reality, visitors are simply waiting for the next available PHP process.

The next step is to inspect the logs. In your web server and PHP logs, look for messages such as upstream timed out, Resource temporarily unavailable, server reached pm.max_children, Allowed memory size exhausted, Maximum execution time exceeded, and HTTP 503 or 504 responses. If these messages appear at the same time as TTFB increases and CloudLinux limits are reached, the issue is unlikely to be a single faulty plugin. It usually indicates that the hosting environment can no longer process requests within its allocated resources.

You should also consider whether your hosting plan provides the diagnostic tools needed for proper optimisation. Troubleshooting a dynamic application often requires access to the MySQL or MariaDB slow query log, the PHP-FPM slow log, PHP-FPM settings such as pm.max_children, pm.max_requests, and memory_limit, OPcache, Redis Object Cache, and the ability to adjust Nginx or Apache configuration. If TTFB remains high, the database is clearly slow, but you cannot enable the slow query log, Redis is unavailable, and PHP-FPM settings cannot be changed, optimisation has reached the limits of the hosting platform rather than the application itself.

If console access is available, you can quickly verify whether Redis is running:

redis-cli ping

A healthy Redis instance returns:

PONG

If Redis is unavailable and your CMS repeatedly executes the same SQL queries for every page request, the database continues performing work that could be served directly from memory. The difference may be barely noticeable on a small website, but on WooCommerce stores, Moodle installations, CRM systems, or large B2B catalogues, the lack of object caching quickly affects the admin area, product filtering, search, shopping baskets, user accounts, and other dynamic features.

Finally, ask yourself the most important question: once you have identified the cause of the slowdown, are you actually able to fix it? If the website is limited by the number of PHP workers, you need access to the PHP-FPM pool configuration. If the database is slow, you need the slow query log and the ability to tune MySQL or MariaDB. If identical SQL queries are repeated constantly, you need Redis or Memcached. If static assets are slow to deliver, you need access to Nginx, HTTP/2, HTTP/3, compression, and cache configuration. When none of these settings are available, optimisation stops not because the root cause is unknown, but because the platform prevents you from resolving it.

You can consider the investigation complete once you have measured TTFB at different times of day, compared dynamic pages with static assets, analysed CloudLinux resource limits, reviewed your web server and PHP logs, checked the availability of Redis, the database slow query log, the PHP-FPM slow log, and confirmed whether Nginx or Apache can be configured. If your diagnostics clearly identify the cause of the slowdown but the hosting platform does not allow you to change the necessary settings, the website has reached the practical limits of shared hosting.

At that point, a Linux VPS is valuable not because it automatically makes the website faster, but because it gives you full control over the server. Instead of simply observing performance bottlenecks, you finally have the tools to eliminate them.

Optimising Nginx and PHP-FPM for Dynamic Websites

Static assets are rarely responsible for a slow website. CSS, JavaScript, images, and fonts are usually delivered within a few milliseconds. The real delay occurs while the server generates the HTML page. When a visitor opens a product page, shopping basket, user account, or admin dashboard, the server must execute PHP code, run dozens or even hundreds of SQL queries, and only then begin sending the response to the browser. This is why a product catalogue may take three seconds to load even though all the images appear almost instantly.

The first step is to confirm that the delay comes from page generation rather than network latency or static file delivery. Measure the TTFB of a dynamic page and compare it with a static asset.

curl -o /dev/null -s -w \
"TTFB: %{time_starttransfer}\nTotal: %{time_total}\n" \
https://example.com/product/

Then run the same test against an image.

curl -o /dev/null -s -w \
"TTFB: %{time_starttransfer}\nTotal: %{time_total}\n" \
https://example.com/images/logo.webp

If the image begins downloading almost immediately while the HTML response takes much longer, the bottleneck is likely to be PHP-FPM, the database, or the application itself.

The next step is to check whether PHP-FPM is running out of available workers. This is a common issue. The server may have plenty of CPU capacity and available memory, yet new requests are forced to wait because every PHP worker is already busy processing previous requests. That is why TTFB often increases sharply during busy periods even though CPU utilisation appears relatively low.

Display the current PHP-FPM processes:

ps -ylC php-fpm --sort=rss

or

ps aux | grep php-fpm

If the number of running processes consistently matches the configured pm.max_children value, new requests are waiting for an available worker.

Next, open the PHP-FPM pool configuration.

It is typically located in one of these directories:

/etc/php/*/fpm/pool.d/
/etc/php-fpm.d/

Pay particular attention to the following settings:

pm
pm.max_children
pm.start_servers
pm.min_spare_servers
pm.max_spare_servers
pm.max_requests

One configuration appears surprisingly often:

pm.max_children = 5

That may be perfectly adequate for a small company website or personal blog. It is usually insufficient for WooCommerce, Moodle, CRM systems, B2B catalogues, or large business portals. One visitor is placing an order, another is searching the catalogue, a third is browsing products, and someone else is working in the admin panel. Once all five workers are occupied, every new visitor has to wait until one becomes available.

Simply increasing pm.max_children is not the answer. Every PHP worker consumes memory. Setting the value too high can cause the server to start swapping or even trigger the Linux Out Of Memory killer.

Start by measuring the average memory consumption of a PHP worker.

ps --no-headers -o rss -C php-fpm | \
awk '{sum+=$1} END {print sum/NR/1024 " MB"}'

Then calculate the number of workers based on the memory actually available.

For example, imagine a VPS with 8 GB of RAM.

Typical memory usage might look like this:

MySQL / MariaDB      1.8 GB
Redis                300 MB
Nginx                150 MB
Operating system     1.2 GB

That leaves approximately 4.5 GB available for PHP-FPM.

If the average PHP process consumes 110 MB, the theoretical maximum becomes:

4500 / 110 ≈ 40 workers

In practice, you should never allocate all available memory to PHP-FPM. The server needs spare capacity for the filesystem cache, temporary workload spikes, and background services. A safer configuration would therefore be:

pm.max_children = 30

or

pm.max_children = 32

Monitor the server for several days after making the change. If pm.max_children is no longer reached while sufficient free memory remains available, the configuration is probably appropriate.

Another setting that is frequently overlooked is pm.max_requests.

PHP processes that remain active for weeks can gradually consume more memory over time. The pm.max_requests parameter automatically recycles each worker after it has handled a specified number of requests.

Typical values include:

pm.max_requests = 500

or

pm.max_requests = 1000

This prevents long-running PHP workers from steadily increasing their memory footprint without interrupting the website.

The next step is to enable the PHP-FPM slow log.

Add the following settings to your pool configuration:

request_slowlog_timeout = 5s
slowlog = /var/log/php-fpm/www-slow.log

After restarting PHP-FPM, every request that runs for more than five seconds will be written to the log.

This is often the point where the real cause of poor performance becomes obvious. Instead of revealing an overloaded server, the slow log identifies the exact section of code responsible for delaying page generation.

Typical examples include:

WordPress plugin
WooCommerce filter
Laravel middleware
Long-running SQL query
External API request

Without the slow log, administrators often troubleshoot by trial and error. They disable plugins, increase PHP worker limits, modify server settings, or even migrate to a larger VPS. Once the slow log is enabled, it usually becomes clear which specific component is responsible for the delay. Problems that might otherwise take hours to isolate can often be identified within minutes.

Next, inspect the Nginx error log:

/var/log/nginx/error.log

Look particularly for messages such as:

upstream timed out
connect() failed
recv() failed
upstream prematurely closed connection

These indicate that the problem occurs during communication between Nginx and PHP-FPM.

If the Nginx log remains clean while the PHP-FPM slow log continues to record long-running requests, the issue almost certainly lies within the application or the database.

After making configuration changes, repeat all of your measurements.

Measure TTFB several times.

Check the number of active PHP workers.

Confirm that pm.max_children is no longer being exhausted.

Review the slow log to ensure that the number of slow requests has decreased.

Finally, open a product page, shopping basket, admin dashboard, and several other dynamic pages simultaneously in separate browser tabs. The response time should remain consistent even when multiple requests are processed in parallel.

The optimisation can be considered successful when new requests no longer wait for an available PHP worker, the PHP-FPM slow log stops recording long-running requests, the Nginx log contains no FastCGI communication errors, and TTFB remains stable under normal production workloads.

Optimising Nginx and PHP-FPM is rarely the final goal. Instead, it removes request queues and provides an accurate picture of how the application behaves under load. Once those bottlenecks have been eliminated, it becomes much easier to determine whether the next step should be enabling Redis, optimising the database, improving SQL queries, or refactoring inefficient application code. That is why tuning PHP-FPM is usually the beginning of serious performance optimisation rather than the end of it.

How to Enable Redis Object Cache or Memcached

Many administrators start by blaming MySQL when the database is simply repeating the same work over and over again. A visitor opens the homepage, WordPress retrieves site settings, active plugins, user roles, theme options, menus, widgets, and dozens of other objects. Seconds later, another visitor opens exactly the same page, and the CMS executes almost the same SQL queries again. Under heavy traffic, the database spends far more time reading identical data than performing genuinely complex operations.

This is precisely the problem that object caching is designed to solve. Redis and Memcached do not replace MySQL or MariaDB. Instead, they store the results of frequently repeated queries in memory, allowing the application to retrieve pre-generated data without querying the database again. The difference may be negligible on a small company website. On WooCommerce, Moodle, Drupal, Magento, Laravel, or large WordPress installations, object caching can eliminate thousands of repetitive SQL queries per minute and significantly reduce database load.

The first step is to confirm that repeated database queries are actually responsible for the slowdown. On WordPress, install Query Monitor. For other applications, enable the MySQL or MariaDB slow query log. If each page request executes hundreds of SQL queries and many of them are identical on every page load, object caching is likely to deliver a measurable improvement.

Query Monitor immediately displays both the number of SQL queries and the total database execution time. If the homepage still executes 250–400 queries even after being reloaded, and the database remains the slowest stage of page generation, enabling Redis becomes the logical next step.

Install Redis.

On Ubuntu:

sudo apt install redis-server

On AlmaLinux or Rocky Linux:

sudo dnf install redis

After installation, verify that the service is running.

systemctl status redis

or

redis-cli ping

A healthy Redis instance returns:

PONG

If Redis is not responding, the application cannot use object caching regardless of the CMS configuration.

Next, enable Redis within the application itself.

On WordPress, the most common solution is the Redis Object Cache plugin. This is where many administrators stop too early. The plugin is installed, the Redis service is running, yet WordPress continues querying MySQL directly.

Open the Redis Object Cache page in the WordPress dashboard and confirm that its status is shown as:

Connected

or

Connected and enabled

If the status displays:

Disabled

or

Not connected

then object caching is not actually being used.

Before measuring performance, make sure the application is genuinely retrieving data from Redis.

Display the Redis statistics:

redis-cli INFO stats

Pay particular attention to:

keyspace_hits
keyspace_misses

A single snapshot tells you very little. A much better approach is to load the same page several times, then check the statistics again.

If keyspace_hits increases much faster than keyspace_misses, the application is successfully retrieving cached data from Redis instead of querying the database for every request.

If both counters barely change, or keyspace_misses continues to grow rapidly, object caching is not working effectively. Common causes include incorrect CMS integration, plugins that constantly flush the cache, inconsistent cache prefixes, or application components that never use Redis in the first place.

It is also worth checking Redis memory usage.

redis-cli INFO memory

If the website is actively being used but Redis occupies only a few hundred kilobytes of memory, review the object cache configuration. In most cases, this indicates that very little data is actually being stored.

Now compare the website before and after enabling Redis.

Before object caching, Query Monitor might report something similar to:

SQL queries:   327
Database time: 820 ms
TTFB:          920 ms

After Redis has been configured correctly, the results often look more like:

SQL queries:   95
Database time: 170 ms
TTFB:          340 ms

The exact figures will vary depending on the CMS, plugins, and application architecture. What matters is the overall trend rather than the absolute numbers. Repeated page loads should execute significantly fewer SQL queries, database execution time should decrease, and TTFB should become both lower and more consistent.

Next, run another series of TTFB measurements.

curl -o /dev/null -s -w \
"TTFB: %{time_starttransfer}\n" \
https://example.com/

Rather than performing a single test, send ten consecutive requests.

The first request is usually the slowest because Redis is still populating its cache. By the second or third request, response times should stabilise, and the variation between measurements should become much smaller.

If enabling Redis has little effect on the number of SQL queries, page generation time remains unchanged, and keyspace_hits barely increases, the issue is unlikely to be server performance. More often, the application is simply not using object caching despite Redis being installed.

Memcached can be tested in much the same way. The main differences lie in its diagnostic tools and caching model. For most modern CMS platforms, Redis is generally the preferred option thanks to its richer feature set, optional data persistence, broader ecosystem, and wider range of production-ready integrations.

The implementation can be considered successful when Redis responds correctly, the CMS actively uses object caching, repeated page loads execute substantially fewer SQL queries, keyspace_hits consistently grows faster than keyspace_misses, and both TTFB and HTML generation times become lower and noticeably more consistent. At that point, the database is no longer repeating the same work for every request, and the server is making effective use of memory instead of repeatedly reading identical data from disk.

How to Verify That a VPS Improves TTFB and Core Web Vitals

Many website owners migrate to a VPS, run PageSpeed Insights, and expect the Reduce initial server response time warning to disappear immediately while Core Web Vitals turn green. In reality, that rarely happens. If PHP-FPM, the database, Redis, OPcache, or Nginx remain configured exactly as they were before, moving to a more powerful server alone is unlikely to produce a significant improvement. To determine whether the VPS has actually made the site faster, compare measurable performance metrics before and after the changes rather than relying on the overall PageSpeed score.

The first step is to establish a performance baseline. Measure the TTFB of several pages that place different types of load on the server. Do not limit your testing to the homepage. Include product pages, category pages, search results, shopping baskets, user account pages, or any other dynamic content. These pages reveal the real impact of PHP execution and database performance.

Run a series of ten consecutive requests.

for i in {1..10}; do
curl -o /dev/null -s -w "%{time_starttransfer}\n" \
https://example.com/product/
done

Save the results for comparison.

The average TTFB is important, but consistency matters just as much. If most responses fall within the 220–260 ms range, the server is performing predictably. If the results fluctuate dramatically—for example 240 ms, 310 ms, 980 ms, 270 ms, and 1150 ms—the bottleneck is more likely to be PHP execution, database performance, or server configuration than raw hardware capacity.

The next step is to identify where the delay occurs. Open the page in your browser, launch Developer Tools, switch to the Network tab, disable the browser cache, and reload the page. Select the initial HTML document and open the Timing tab.

If Waiting (TTFB) accounts for most of the time before the first byte is received, the server is spending too long generating the HTML response. If Waiting is relatively short but delays occur while downloading CSS, JavaScript, or images, the bottleneck lies elsewhere.

Next, inspect the server itself.

If PHP-FPM is in use, verify that requests are not waiting for available workers.

Review the PHP-FPM slow log.

Inspect the MySQL or MariaDB slow query log.

Confirm that OPcache is enabled.

php -i | grep opcache.enable

If Redis Object Cache is enabled, verify that the Redis service is running.

redis-cli ping

Then confirm that the application is actually using the cache.

redis-cli INFO stats

If keyspace_hits increases steadily during repeated page requests, Redis is successfully reducing the number of database queries.

Once you have made your configuration changes, repeat exactly the same tests. Use the same pages, the same number of requests, and, where possible, perform the measurements at the same time of day. Only then can you compare the results objectively.

For example, before optimisation, repeated tests of a dynamic page might produce results such as:

TTFB

910 ms
840 ms
1020 ms
760 ms
880 ms

The average response time is approximately 880 ms, with a variation of more than 250 ms. From the visitor's perspective, this inconsistency is experienced as an intermittently slow website.

After tuning PHP-FPM, enabling Redis, activating OPcache, and optimising the database, the results might look like this:

TTFB

205 ms
214 ms
198 ms
221 ms
209 ms

The average falls to around 210 ms, while the variation is reduced to only a few tens of milliseconds. This level of consistency is usually perceived by users as a fast and responsive website.

Now run PageSpeed Insights or Lighthouse again. When the HTML document arrives sooner, the browser can begin downloading CSS, JavaScript, images, and the Largest Contentful Paint element much earlier. As a result, the Reduce initial server response time warning may disappear completely or become far less significant. LCP often improves, and INP may also benefit because the browser completes the initial page load more efficiently.

The verification can be considered successful when four conditions are met simultaneously:

Your measurements show not only a lower average TTFB but also significantly more consistent response times.

Developer Tools confirms that Waiting (TTFB) has been reduced.

PHP-FPM, Redis, OPcache, and the database operate without worker queues, long-running queries, or signs of resource exhaustion.

The improvements are visible not only in PageSpeed Insights or Lighthouse but also during normal day-to-day use of the website.

When all of these indicators improve together, you can be confident that the performance gain comes from proper VPS optimisation rather than a single favourable benchmark result.

How to Check the Network Performance of Your VPS

There are situations where the server generates HTML in 150–200 ms, PHP-FPM has no worker queues, Redis is running, and the database responds quickly, yet users still complain that the website feels slow. In cases like these, the bottleneck is often no longer the application itself but the network layer. The HTML document arrives promptly, while images, CSS, JavaScript, PDF files, or video content take much longer to download than expected. This is particularly noticeable on pages containing many assets or when several files are being downloaded simultaneously.

The first step is to confirm that the delay occurs during file delivery rather than page generation. Open your browser's Developer Tools, switch to the Network tab, disable browser caching, reload the page, and sort requests by duration. If the initial HTML document arrives quickly but CSS, JavaScript, or images begin downloading much later or take significantly longer to complete, the next stage of troubleshooting should focus on the server's network configuration.

Next, verify which HTTP protocol your web server is using. If the site still relies on HTTP/1.1, the browser must establish multiple separate connections to download a large number of resources. HTTP/2 allows multiple assets to be transferred over a single connection, while HTTP/3 further reduces the impact of packet loss and high-latency networks.

Check whether HTTP/2 is enabled:

curl -I --http2 https://example.com

If HTTP/2 is available, the response headers will indicate the negotiated protocol.

To test HTTP/3, run:

curl -I --http3 https://example.com

If the connection is successfully established over HTTP/3, your server already supports the newer transport protocol. If not, review the configuration of Nginx, Apache, or any reverse proxy sitting in front of the application.

The next step is to confirm that response compression is enabled. Surprisingly often, HTML, CSS, and JavaScript are still delivered uncompressed even though every modern browser supports compressed content.

Inspect the response headers:

curl -I https://example.com

Look for either of the following headers:

Content-Encoding: gzip

or

Content-Encoding: br

If neither header appears for HTML, CSS, or JavaScript responses, the server is transferring significantly more data than necessary. The impact becomes particularly noticeable on pages containing large stylesheets and JavaScript bundles.

Now evaluate the size of the page itself. Sometimes the problem has nothing to do with network performance at all. A homepage weighing 8–10 MB because of oversized images, multiple JavaScript libraries, and background videos will load slowly regardless of how powerful the VPS is.

In Developer Tools, check the Transferred column to see the total amount of data downloaded for the page. If several megabytes are being transferred, optimise images, reduce or combine CSS and JavaScript files, and eliminate unnecessary assets before investigating the network any further.

The next step is to measure the download speed of a large file served directly from the VPS.

For example:

curl -o /dev/null -s -w \
"Download: %{speed_download} bytes/sec\nTotal: %{time_total}\n" \
https://example.com/testfile.iso

or any other file that is at least several hundred megabytes in size.

The size of the test file matters. Measuring throughput with a 200–300 KB image tells you almost nothing because modern network connections transfer files of that size almost instantly. Use a file between 200 MB and 500 MB, or larger if available. During the download, watch how the transfer speed behaves. If it quickly reaches a stable rate and remains consistent, the VPS network stack is probably functioning correctly. If throughput fluctuates dramatically—for example between 10 MB/s and 90 MB/s—drops to almost zero, or the transfer repeatedly stalls, the issue is more likely to be related to network infrastructure, bandwidth limits, storage performance, or web server configuration.

Afterwards, inspect the current utilisation of the network interface. Sometimes the website becomes slow simply because the available bandwidth is already being consumed by backup jobs, file synchronisation, large imports, or other background activity.

Useful tools include:

iftop

or

vnstat

iftop displays live network connections and bandwidth usage in real time, while vnstat provides historical traffic statistics over hours or days. If user complaints coincide with periods where the network interface is consistently operating near its maximum capacity, the cause of the slowdown becomes immediately apparent.

It is also worth checking your keepalive configuration. If every request closes the connection, the browser must perform a new TCP and TLS handshake before downloading the next resource. On pages containing dozens of files, this additional overhead can noticeably increase total page load time even when the server itself responds quickly.

Finally, determine whether the project actually needs a Content Delivery Network (CDN). Many administrators enable one immediately after deploying a VPS, expecting it to improve performance under all circumstances. In reality, the benefit depends largely on where your visitors are located.

If most users are in a single country or neighbouring regions and the VPS is hosted close to them, a properly configured server will often deliver static assets almost as quickly as a CDN. In this scenario, a CDN may reduce server load, but visitors are unlikely to notice a dramatic improvement in page speed.

The picture changes completely for international websites. If the server is located in Germany while a significant proportion of visitors access the site from North America, Australia, Japan, or South America, latency becomes limited by geography rather than server performance. A CDN stores images, CSS, JavaScript, and other static assets on edge servers much closer to those users, allowing resources to be delivered significantly faster without any changes to the application itself.

Before enabling a CDN, review your audience distribution using your web analytics platform. If most visitors come from one geographic region, optimise the server first. If traffic is spread across multiple continents, a CDN is no longer simply an optional optimisation—it becomes an important part of the overall infrastructure.

The network layer can be considered properly configured when HTML is generated and delivered quickly, HTTP/2 or HTTP/3 is enabled, gzip or Brotli compression is active for text-based resources, page sizes remain reasonable, large files are transferred at speeds consistent with the available network capacity, the network interface is not permanently saturated, and users receive static assets without unnecessary delays.

If the website still feels slow after all of these checks, the network is unlikely to be the culprit. The remaining bottleneck is usually found inside the application itself, the database, external APIs, or the application's request processing logic. Troubleshooting the infrastructure layer by layer in this way allows you to eliminate each potential cause methodically instead of spending time tuning components that are already performing as expected.

How to Choose a Linux KVM VPS for Better Website Performance

Most people begin choosing a VPS by comparing specifications. They look at the number of CPU cores, the amount of RAM, the size of the NVMe storage, and sometimes the processor frequency. These specifications certainly matter, but in production environments website performance is much more often limited by something else. If you cannot tune PHP-FPM, enable Redis, optimise Nginx, analyse slow query logs, or configure OPcache, adding more hardware resources will not necessarily solve the problem. The server becomes more powerful, yet pages continue to load at almost exactly the same speed.

The first step before ordering a VPS is to identify which optimisation tools your project will actually need. If the website is already experiencing performance issues, use the results of your previous diagnostics. Determine where the delays occur. Are PHP workers running out? Is the database executing hundreds of identical SQL queries? Does TTFB increase during peak traffic? Were you unable to enable Redis, activate the slow query log, or adjust PHP-FPM settings? The answers to these questions are far more useful when choosing a VPS than simply comparing processors or memory capacity.

Next, evaluate the platform based on the level of control it provides rather than its hardware specifications. You should be able to modify PHP-FPM settings, configure Nginx or Apache, install Redis or Memcached, enable OPcache, analyse MySQL or MariaDB slow query logs, inspect server logs, and use technologies such as HTTP/2, HTTP/3, and Brotli that have a measurable impact on website performance. If every configuration change requires contacting technical support, meaningful optimisation quickly becomes slow, frustrating, and difficult to maintain.

It is also worth thinking ahead before you deploy the server. Imagine that your traffic doubles within a year, your developers upgrade to a newer PHP release, introduce Redis, background queues, Elasticsearch, scheduled tasks, or additional Docker containers. If your chosen VPS can accommodate those changes without requiring a migration to a completely different platform, you are making a sound long-term decision. If future improvements already appear constrained by the hosting plan or infrastructure, it is better to solve that problem before the project goes live.

Diagnostic capabilities are just as important. Most serious performance problems are resolved by identifying the real bottleneck rather than by adding CPU cores or memory. Being able to inspect Nginx, PHP-FPM, MySQL, or MariaDB logs, monitor CPU usage with htop, analyse network activity, enable slow logging, or install additional troubleshooting tools often proves far more valuable than having two extra processor cores.

If you reduce the selection process to a simple workflow, it becomes much easier to make the right decision.

First, identify exactly what is limiting your website's performance today.

Next, confirm that the VPS gives you full control over the components responsible for those bottlenecks.

Finally, make sure the platform will continue to support your project as it grows over the next several years without requiring major architectural changes or disruptive migrations.

This approach is almost always more reliable than simply choosing the plan with the largest amount of CPU and RAM.

Your evaluation can be considered complete when the chosen Linux KVM VPS provides full administrative control over the software stack, allowing you to configure PHP-FPM, Nginx, Redis, Memcached, OPcache, MySQL or MariaDB, use HTTP/2 and HTTP/3, analyse logs and performance metrics, and scale hardware resources as the project grows without significant operational restrictions.

CPU cores and memory determine how much computing capacity is available. Website performance depends on how efficiently that capacity is used. That is why an experienced administrator chooses a Linux KVM VPS not simply for its hardware specifications, but for the level of control it provides over the entire server environment. The ability to diagnose bottlenecks, optimise every layer of the software stack, and adapt the platform as the project evolves is what ultimately delivers consistently fast page generation, lower TTFB, and predictable performance over the long term.