Most “slow server” complaints aren’t raw CPU issues. More often, PHP-FPM is under- or over-provisioned, microcaching is missing, or Nginx is doing work the kernel can handle faster. This Nginx performance optimization tutorial focuses on changes you can apply on an Ubuntu VPS to lower TTFB, smooth load spikes, and keep WordPress and other PHP apps stable under real traffic.
The examples assume Ubuntu Server 24.04 LTS with Nginx 1.24+ and PHP 8.3/8.4 via PHP-FPM. The same approach works on Debian 12/13 and AlmaLinux/Rocky. You’ll mainly adjust file paths and service names.
Before you change anything: baseline your VPS (5 minutes)
If you skip the baseline, you’ll end up tuning by feel. Grab three quick signals: (1) TTFB, (2) requests per second under light load, and (3) how much CPU/RAM/disk headroom you have.
1) Quick TTFB check from your laptop
curl -o /dev/null -s -w \
"DNS:%{time_namelookup} Connect:%{time_connect} TLS:%{time_appconnect} TTFB:%{time_starttransfer} Total:%{time_total}\n" \
https://example.com/On a typical WordPress page running on a modest VPS, consistency matters more than a single “best” number. Big TTFB spikes usually point to PHP-FPM queueing, database waits, or disk I/O stalls.
2) Snapshot server health
uname -a
nginx -v
php-fpm8.3 -v 2>/dev/null || php-fpm8.4 -v
free -h
df -h
uptime
top -o %CPU3) Enable a simple access log format for timing
Edit your main Nginx config (usually /etc/nginx/nginx.conf). Add a log format that includes upstream timing.
Then reload Nginx so the change takes effect.
sudo nano /etc/nginx/nginx.confhttp {
log_format timed '$remote_addr - $host [$time_local] "$request" '
'$status $body_bytes_sent '
'rt=$request_time urt=$upstream_response_time '
'uaddr=$upstream_addr cache=$upstream_cache_status';
}
sudo nginx -t && sudo systemctl reload nginxThis makes troubleshooting simpler. If Nginx is fast but upstream timing is slow, PHP (or the database behind it) is the bottleneck.
Hosting note: If you’re applying these changes on a production site, you’ll want predictable CPU/RAM and full root access. A HostMyCode VPS gives you that control. Shared hosting usually doesn’t.
Nginx performance optimization tutorial: core tuning that pays off
These settings won’t “fix” slow application code. They do remove common Nginx bottlenecks and improve concurrency under load.
1) Tune worker processes and connections
Open /etc/nginx/nginx.conf and set worker values. Use auto so Nginx matches your CPU cores without guesswork.
sudo nano /etc/nginx/nginx.confworker_processes auto;
worker_rlimit_nofile 200000;
events {
worker_connections 4096;
multi_accept on;
use epoll;
}
Then align OS limits (Ubuntu runs Nginx under systemd):
sudo systemctl edit nginx[Service]
LimitNOFILE=200000sudo systemctl daemon-reload
sudo nginx -t && sudo systemctl restart nginx2) Turn on sendfile + sane TCP options
Still in the http {} block:
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 15;
keepalive_requests 1000;
sendfile and tcp_nopush reduce CPU overhead for static files. You’ll notice it most if the VPS serves images, CSS, and JS directly.
3) Use open_file_cache for static assets
This cuts down repeated filesystem lookups during busy periods.
open_file_cache max=50000 inactive=60s;
open_file_cache_valid 120s;
open_file_cache_min_uses 2;
open_file_cache_errors on;
4) Switch access logging to “only when needed” (optional)
Access logs are valuable for troubleshooting. At high request rates, they can also become expensive.
Keep your timing log while you’re tuning. Once things are stable, consider sampling or turning off logging for noisy endpoints.
Enable fast compression (gzip, and Brotli if available)
Compression mainly improves bandwidth and time-to-render, especially on mobile. It won’t rescue slow PHP. It does reduce transfer time and helps clients with limited connections.
Gzip (built-in)
Add inside http {}:
gzip on;
gzip_comp_level 5;
gzip_min_length 1024;
gzip_vary on;
gzip_proxied any;
gzip_types
text/plain
text/css
text/xml
application/json
application/javascript
application/xml
application/xml+rss
image/svg+xml;
Brotli (if your Nginx build supports it)
Many repos ship Brotli as a dynamic module. If you see --with-compat and Brotli modules are available, enable them and configure:
brotli on;
brotli_comp_level 5;
brotli_types text/plain text/css application/json application/javascript image/svg+xml;
If Brotli isn’t available, skip it. Gzip at level 5 is a sensible default for most VPS setups.
HTTP/2 and HTTP/3: correct setup on TLS vhosts
HTTP/2 should be your default for TLS sites. HTTP/3 can help on flaky networks, but it’s optional and easier to misconfigure.
HTTP/2 (recommended)
In your TLS server block (often in /etc/nginx/sites-available/example.com), ensure:
listen 443 ssl http2;
If you still need to issue or fix certificates, follow HostMyCode’s Let’s Encrypt walkthrough: SSL certificate setup for Nginx on Ubuntu (2026).
HTTP/3 (optional, verify your build first)
HTTP/3 requires QUIC support in your Nginx package/build. If you have it, you’ll usually add a UDP listener and an Alt-Svc header.
Test carefully across browsers and networks. Partial support can lead to confusing client behavior.
Microcaching: the easiest win for WordPress and PHP pages
Microcaching stores responses for a few seconds. That’s long enough to soak up bursts (homepage hits, bot spikes, social traffic) without keeping content stale for minutes.
On WordPress, it can cut upstream PHP requests sharply during peaks.
Create a cache zone
Add in http {}:
proxy_cache_path /var/cache/nginx/microcache
levels=1:2
keys_zone=microcache:100m
inactive=10m
max_size=2g
use_temp_path=off;sudo mkdir -p /var/cache/nginx/microcache
sudo chown -R www-data:www-data /var/cache/nginxUse it in the PHP site config (FastCGI cache)
If your PHP runs via PHP-FPM (common), use FastCGI caching rather than proxy caching. Add in http {}:
fastcgi_cache_path /var/cache/nginx/fastcgi
levels=1:2
keys_zone=phpcache:100m
inactive=10m
max_size=2g;Then in your server block, inside the location ~ \.php$ or your WordPress location / handling (depending on your layout), add:
set $skip_cache 0;
# Don’t cache logged-in users or carts.
if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_logged_in") {
set $skip_cache 1;
}
if ($request_method != GET) { set $skip_cache 1; }
if ($query_string != "") { set $skip_cache 1; }
fastcgi_cache phpcache;
fastcgi_cache_valid 200 301 302 10s;
fastcgi_cache_use_stale updating error timeout invalid_header http_500 http_503;
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;
add_header X-FastCGI-Cache $upstream_cache_status always;WordPress pitfall: If you run WooCommerce or membership plugins, tighten your bypass rules. After enabling caching, test checkout, login, and account pages end to end.
If you want a safer workflow for testing changes before production, use a staging setup: WordPress staging on a VPS with Nginx + SSL.
PHP-FPM tuning: stop queueing and memory thrash
On PHP sites, PHP-FPM settings often decide whether the stack feels fast or randomly stalls. Your goal is simple.
Run enough workers for normal concurrency, but not so many that the server swaps or runs out of RAM.
1) Find your PHP-FPM pool config
Common paths on Ubuntu:
/etc/php/8.3/fpm/pool.d/www.conf/etc/php/8.4/fpm/pool.d/www.conf
2) Measure typical PHP memory usage
After peak traffic, check worker RSS:
ps -ylC php-fpm8.3 --sort:rss | awk 'NR==1{print} NR<=10{print}'
Use the RSS column (in KB) as your guide. WordPress with plugins often sits around 80–150MB per worker. Heavy page builders can run higher.
3) Set pm mode and worker counts
For many VPS WordPress installs, pm = ondemand is a good starting point. If the site stays busy all day, dynamic usually avoids cold-start latency.
Example for a 4GB VPS where PHP workers average ~120MB RSS:
pm = dynamic
pm.max_children = 16
pm.start_servers = 4
pm.min_spare_servers = 4
pm.max_spare_servers = 8
pm.max_requests = 500The math matters. 16 × 120MB is roughly 1.9GB for PHP.
That leaves room for Nginx, the OS page cache, and anything else running on the box. Adjust based on your measured RSS and total RAM.
4) Restart PHP-FPM and watch for queuing
sudo systemctl restart php8.3-fpm || sudo systemctl restart php8.4-fpm
sudo tail -n 50 /var/log/php8.3-fpm.log 2>/dev/null || trueIf you see “server reached pm.max_children” or frequent slow log entries, the pool is saturated. You can raise pm.max_children if RAM allows.
In practice, caching often delivers bigger wins with less risk.
Static asset caching headers (cheap performance)
Your browser should cache versioned static assets for a long time. That reduces repeat load times and saves bandwidth on every revisit.
Add a static file location block in your server config:
location ~* \.(css|js|jpg|jpeg|png|gif|ico|svg|webp|avif|ttf|woff|woff2)$ {
expires 30d;
add_header Cache-Control "public, max-age=2592000, immutable";
access_log off;
}
Do not apply long caching to HTML unless you fully understand your page caching strategy and invalidation.
Protect performance under abuse: rate-limit the expensive endpoints
WordPress login, XML-RPC (if enabled), and search can burn CPU quickly. Rate limiting is both a performance tool and a security control.
It keeps real users from competing with bots for PHP workers.
Follow HostMyCode’s step-by-step guide, then come back here and measure the difference:
Quick diagnostics: prove what got faster (or what broke)
After each change, do two things: validate the config and run a quick timing check. Don’t stack five changes at once and hope for the best.
1) Validate and reload safely
sudo nginx -t
sudo systemctl reload nginx2) Confirm caching headers and cache status
curl -I https://example.com/ | egrep -i 'x-fastcgi-cache|cache-control|expires|server'If FastCGI cache is working, repeat requests to a cacheable page should show X-FastCGI-Cache: HIT.
3) Watch request time vs upstream time
sudo tail -f /var/log/nginx/access.logUse your timing fields to narrow the problem. If rt is high but urt is low, Nginx is likely waiting on I/O (disk/network) or buffering. If urt is high, PHP is slow or queueing.
Deployment checklist (use this every time)
- Run
nginx -tbefore reload. - Keep an SSH session open while reloading, in case you need to revert.
- Change one major thing at a time: caching, then PHP-FPM, then headers.
- Test logged-in and logged-out flows (especially WooCommerce).
- Verify TLS after changes:
curl -I https://example.com. - Capture before/after TTFB with the same command and endpoint.
Common mistakes that slow Nginx sites on a VPS
- Too many PHP workers: it looks fine until traffic rises, then the box swaps and everything slows.
- No caching, but heavy plugins: WordPress can render slowly even on fast CPUs if every request hits PHP + database.
- Caching logged-in pages: users see other users’ content or broken carts. Always bypass by cookie and method.
- Ignoring bots: a low-grade crawl can eat your CPU and make real users wait.
- Unlimited logs: giant access logs fill disks and trigger emergency I/O throttling.
Summary: a practical path to a faster Nginx stack
Measure first. Then tune Nginx workers and file handling, enable compression, and add microcaching.
After that, right-size PHP-FPM so it doesn’t queue or churn memory. The payoff is steadier TTFB and fewer “random slow” moments during traffic spikes.
If you want these optimizations on predictable resources (NVMe storage, dedicated RAM, and full root access), run your stack on a managed VPS hosting plan from HostMyCode. Or choose a self-managed HostMyCode VPS if you prefer hands-on control.
If your site is outgrowing shared hosting, a VPS gives you access to the same tuning controls used here: PHP-FPM pool sizing, Nginx caching, and log-based troubleshooting. Start with a HostMyCode VPS, or choose managed VPS hosting if you want help with setup, hardening, and performance tuning.
FAQ
Will microcaching break WordPress admin or WooCommerce?
Not if you bypass cache for logged-in users, non-GET methods, and common cart/session cookies. Always test checkout, login, and account pages after enabling caching.
Should I use HTTP/3 on my VPS?
Use HTTP/2 first. Enable HTTP/3 only if your Nginx build supports QUIC and you can test across browsers and networks. It helps most on lossy mobile connections.
How do I know if PHP-FPM is the bottleneck?
Check Nginx timing logs. If upstream_response_time is consistently high, PHP is slow or queueing. If it’s low but request_time is high, look at I/O, buffering, or network issues.
What’s the safest “first change” for performance?
Add static asset caching headers and gzip compression. They’re low-risk and easy to verify with curl -I. Then move to microcaching and PHP-FPM sizing.