Increasing the speed of the website on the virtual server is one of the most important tasks that has a direct impact on the user experience, conversion rate and your SEO ranking. Unlike shared hosting where you share resources with dozens of other sites, on a virtual server you have complete control over CPU, RAM, disk and software configuration; For this reason, there is the potential to reach sub-200ms response time and a green score in Core Web Vitals. In this practical guide, we show you step-by-step with real commands how to turn a slow web server into a high-speed machine.
Before any optimization, you should know that the speed of a website consists of a chain of layers: DNS, TLS connection, server response time (TTFB), client-side rendering and static resource loading. A wrong setting in any layer can nullify all your efforts in other layers. So our approach is to measure, identify bottlenecks, and then make targeted optimizations, not blind changes.
Why is website speed important on a virtual server?
From 2021, Google introduced the Core Web Vitals criteria as an official ranking factor. The three key metrics are LCP (largest viewable content, target under 2.5 seconds), INP (engagement to next draw, target under 200ms) and CLS (cumulative layout displacement, target under 0.1). Industry statistics show that for every one second of loading delay, the bounce rate increases by 32% and the conversion rate decreases by 7%.
On a virtual server, the most important metric you can directly monitor is TTFB, or Time To First Byte. A well-tuned server should provide TTFB below 200ms; If you see a number above 600ms, it is almost always the fault of server-side software configuration, heavy database queries, or lack of cache, not bandwidth.
Measuring the current situation
Before making changes, record the baseline so you can measure improvement. You can see the exact timing of each step with the curl command line tool:
curl -w "DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTLS: %{time_appconnect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" -o /dev/null -s https://example.comThis output tells you where time is wasted. If TLS is high, go for certificate and protocol optimization; If TTFB is high, the problem is in the backend.
Choosing and configuring the right web server
To increase the speed of the website, choosing a web server and how to configure it is the starting point. Nginx is the superior choice in most scenarios due to its event-driven architecture and low memory consumption, and can handle thousands of simultaneous connections with a few megabytes of RAM, while traditional Apache creates a single process or thread for each connection.
Enable HTTP/2 and HTTP/3
The HTTP/2 protocol transmits multiple requests over a single TCP connection with multiplexing, greatly reducing latency. To activate it in Nginx, just add the http2 parameter to the listen block:
server {
listen 443 ssl http2;
server_name example.com;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
}Enabling TLS 1.3 alone can eliminate a round-trip of connection loss and shorten the time to establish a secure connection by 30%. ssl_session_cache also prevents TLS renegotiation for returning users.
Gzip and Brotli compression
Text compression (HTML, CSS, JavaScript) can reduce the transfer volume by 70-80%. Brotli typically outperforms Gzip by 15-20%. Example configuration of Gzip in Nginx:
gzip on;
gzip_comp_level 5;
gzip_min_length 256;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml image/svg+xml;
gzip_vary on;Note that compression levels higher than 5 for Gzip usually require more CPU but provide a small size savings; The number 5 is a good balance.
Optimization of PHP and backend layer
If your site is WordPress or PHP-based, the code execution layer is often the biggest TTFB bottleneck. It is critical to use PHP-FPM instead of mod_php and set the number of processes correctly.
OPcache setting
OPcache keeps compiled PHP bytecode in memory and avoids recompilation on every request; This alone can reduce PHP execution time by 50%. Recommended configuration in php.ini:
opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0
opcache.jit=1255
opcache.jit_buffer_size=128MThe validate_timestamps=0 parameter in the production environment increases the speed because PHP no longer checks for file changes; But remember to reset OPcache after each new deployment. The JIT in PHP 8 is also beneficial for heavy computing loads.
Correct PHP-FPM Pool Setup
The number of PHP-FPM processes should be proportional to the server's RAM. Simple formula: Maximum processes is equal to allocable RAM divided by the average consumption of each process (usually 40-80 MB). For a server with 4 GB of RAM that you allocate 2 GB for PHP:
pm = dynamic
pm.max_children = 30
pm.start_servers = 8
pm.min_spare_servers = 6
pm.max_spare_servers = 12
pm.max_requests = 500The max_requests parameter prevents memory leaks; After every 500 requests, the process is regenerated. If you set this number too high, the server may overrun the RAM.
Implementation of cache in multiple layers
Caching is the most effective tool to increase website speed. A good caching strategy has several layers: bytecode cache (OPcache), object cache (Redis), full page cache (page cache) and browser cache.
Full page cache with Nginx FastCGI Cache
With full page caching, Nginx caches the HTML output and subsequent requests never reach PHP at all. This can reduce the TTFB from a few hundred milliseconds to less than 10 milliseconds:
fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=WPCACHE:100m inactive=60m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";
location ~ \.php$ {
fastcgi_cache WPCACHE;
fastcgi_cache_valid 200 60m;
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;
add_header X-Cache $upstream_cache_status;
}The X-Cache header tells you if the request was a HIT (from cache) or a MISS (processed). For dynamic pages such as shopping cart or user panel, set the skip_cache variable based on the cookie so that they are not cached.
Browser cache for static files
By setting the Cache-Control and Expires headers, the user's browser caches the image, CSS, and JS files and does not request the server on subsequent visits:
location ~* \.(jpg|jpeg|png|gif|webp|css|js|woff2|svg)$ {
expires 365d;
add_header Cache-Control "public, immutable";
access_log off;
}Key point: For files that may change, use versioning in the file name like style.a1b2c3.css so that you can deliver the new version to the user with a long cache.
Optimization of images and frontend resources
Images usually make up more than 50% of a page. Converting to modern formats such as WebP and AVIF can reduce the size by 25-50% compared to JPEG without noticeable quality loss.
- Lazy Loading: By adding loading="lazy" to img tags, out-of-view images are loaded only when scrolling.
- Explicit dimensions: Always specify the width and height of images to avoid layout displacement (CLS).
- Minify: Compress CSS and JS files by removing spaces and descriptions to reduce the size by 20-30%.
- Remove blocking resources: Load unnecessary scripts with defer or async so the initial rendering doesn't stop.
You can use cwebp tool to batch convert images to WebP on the server:
find /var/www/uploads -name "*.jpg" -exec sh -c 'cwebp -q 80 "$1" -o "${1%.jpg}.webp"' _ {} \;Network optimization and delay reduction
Even with the best software configuration, network latency can account for a significant portion of load time. The first step is to use the correct keep-alive settings to keep TCP connections open for successive requests and avoid reconnection costs. A new TCP connection requires a full round-trip, and latency accumulates if a new connection is opened for each file.
keepalive_timeout 65;
keepalive_requests 1000;
tcp_nodelay on;
tcp_nopush on;
sendfile on;The sendfile parameter allows the kernel to send static files directly to a network socket without additional userspace copying, which reduces CPU consumption. The combination of tcp_nopush and sendfile makes headers and the beginning of the file sent in an optimal packet.
Kernel configuration for high traffic
On high-traffic servers, the default Linux kernel settings may be restrictive. Increasing connection queue and optimizing TCP parameters can make a noticeable difference. The BBR congestion control algorithm developed by Google improves throughput over the default cubic algorithm in many scenarios:
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535
net.ipv4.tcp_congestion_control = bbr
net.core.default_qdisc = fqPut these settings in the /etc/sysctl.conf file and apply them with the sysctl -p command. Enabling BBR is especially useful for users with lower network quality or greater geographical distance, as it copes better with packet loss.
Using a content distribution network
For websites with a large audience, no amount of server-side optimization can make up for the physical distance. A content distribution network (CDN) keeps a copy of your static files on servers close to the user, drastically reducing latency. For image-heavy content and download files, this can improve load times for remote users many times over, while also reducing the load on the main server.
Monitoring and maintaining performance over time
Increasing website speed is not a one-time task; As traffic grows and content increases, new bottlenecks appear. Tools like htop for live CPU and RAM usage, and external tools like PageSpeed Insights or WebPageTest are essential for measuring the real user experience.
| Indicator | The desired goal | Needs improvement |
|---|---|---|
| TTFB | Under 200ms | Above 600ms |
| LCP | Below 2.5s | Above 4s |
| INP | Under 200ms | Above 500ms |
| CLS | Below 0.1 | Above 0.25 |
If you are looking for a reliable infrastructure to implement these optimizations, you can use our powerful servers. To buy a virtual server with dedicated resources and high-speed network, choose the right plan for your business. Additional material is also available in Rapido Server Articles.
Another important point is the correct prioritization of actions. With limited time, it's best to go for the changes that will have the most impact with the least effort first. Experience shows that in most sites, implementing a page cache, enabling OPcache, compressing and optimizing images provide more than 80% of the possible improvement. Smaller kernel and network settings have a complementary effect, and you should refer to them in the next steps.
Finally, remember that speed optimization is an iterative process: measure, make a change, measure again, and measure the effect. Small, consistent changes over time will lead to a blazing fast website that both users and search engines will love. Investing in speed is investing in conversion rates, user satisfaction, and sustainable SEO rankings.
Frequently asked questions
What is the most important factor that I should optimize to increase the speed of the website on the virtual server?
In most cases, implementing a full page cache and object cache is most effective, as it answers requests before they reach PHP and the database, reducing TTFB from hundreds of milliseconds to under 50 milliseconds. After that, enabling OPcache and compressing Brotli are the most efficient.
Does increasing the RAM and CPU of the server alone make the site faster?
Not necessarily. If your bottleneck is software configuration or heavy database queries, adding hardware resources will only mask the problem. First, identify the real bottleneck with monitoring tools; In many cases, by properly configuring the cache and PHP-FPM, more traffic can be handled on the same hardware.
What is the right TTFB for a website?
Google considers a TTFB below 800ms acceptable, but a professional goal is below 200ms. With a full page cache and a server geographically close to users, it is quite possible to achieve a TTFB under 100ms.
How do I know if my optimizations really worked?
Before and after each change, measure metrics with tools like curl (for TTFB) and PageSpeed Insights (for Core Web Vitals) and record the results. Keep the change only when it has made a definite numerical improvement; This data-driven approach avoids ineffective or harmful settings.
