Nginx Performance Optimization: Tips for Faster Websites

Slow sites usually come from a handful of causes: expensive upstream responses, missing cache headers, oversized assets, blocked workers, or a server that is tuned for defaults instead of your traffic. Nginx performance optimization works best when you measure first, change one setting at a time, and keep the configuration readable.

Use the examples below as starting points, then load test them against your own app. A static file server, a WordPress/PHP-FPM site, and an API reverse proxy need different tradeoffs.

Understanding Nginx Performance Bottlenecks

Start by finding the bottleneck. Common causes include:

CPU usage: High CPU load slows request handling, compression, and TLS work.
Memory pressure: Swapping hurts latency badly.
Network I/O: Slow links, small upstream windows, or packet loss can dominate response time.
Disk I/O: Static files, cache files, and logs still touch storage.
Upstream latency: Nginx can be fast while your app server is slow.

Tools like top, htop, iostat, ss, access logs, and Nginx's stub_status module can help you decide what to tune.

Core Nginx Optimization Techniques

Worker Processes and Connections

The worker_processes directive controls how many worker processes Nginx starts. auto is a practical default because Nginx detects the available CPU cores.

# Set worker_processes to the number of CPU cores
worker_processes auto;

Within each worker process, worker_connections limits how many simultaneous connections that worker can open. The rough upper bound is worker_processes * worker_connections, but real capacity also depends on upstream connections, open file limits, keep-alive behavior, and operating system limits.

# Increase worker_connections for high traffic sites
worker_connections 1024;

If you see Too many open files, raising worker_connections alone is not enough. Also check the service's file descriptor limit, often controlled by systemd LimitNOFILE or shell limits.

Caching Strategies

Caching is usually the highest-impact Nginx performance optimization because it prevents repeated work.

Browser Caching

Tell browsers to cache versioned static assets such as images, CSS, and JavaScript. Use long lifetimes only when filenames change on deploy, such as app.8f3c1.css.

location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
    expires 30d;
    add_header Cache-Control "public";
}

Proxy Caching

If Nginx is a reverse proxy, it can cache selected backend responses. This works well for public pages, API responses with clear freshness rules, and expensive pages that do not vary per user.

First, define a cache zone in the http block:

http {
    # ... other http configurations ...
    proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=1g inactive=60m;
    # ...
}

/var/cache/nginx: The directory where cache files will be stored.
levels=1:2: Defines the directory structure for the cache.
keys_zone=my_cache:10m: Creates a shared memory zone named my_cache with 10MB size to store cache keys.
max_size=1g: Sets the maximum size of the cache.
inactive=60m: Removes cache entries that haven't been accessed for 60 minutes.

Then, enable caching in your location block:

location / {
    proxy_pass http://your_backend_app;
    proxy_cache my_cache;
    proxy_cache_valid 200 302 10m; # Cache 200 and 302 responses for 10 minutes
    proxy_cache_valid 404 1m;     # Cache 404 responses for 1 minute
    add_header X-Cache-Status $upstream_cache_status;
}

add_header X-Cache-Status $upstream_cache_status; is useful for debugging, showing whether a request was a cache hit, miss, or bypass.

Do not cache personalized pages unless your cache key accounts for the data that changes the response. For example, a logged-in dashboard should usually bypass proxy cache, while /assets/logo.png can be cached for a long time.

Compression

Compression reduces transfer size for text-based responses such as HTML, CSS, JavaScript, JSON, and XML. It does not help much for already-compressed files such as JPEG, PNG, MP4, or many archive formats.

http {
    # ...
    gzip on;
    gzip_vary on;
    gzip_proxied any;
    gzip_comp_level 6;
    gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
    # ...
}

gzip on;: Enables Gzip compression.
gzip_vary on;: Adds the Vary: Accept-Encoding header, which is important for caching proxies.
gzip_proxied any;: Compresses responses for proxied requests as well.
gzip_comp_level 6;: Sets the compression level (1-9, higher means better compression but more CPU).
gzip_types ...;: Specifies the MIME types to compress.

Brotli can compress text assets well, but standard open source Nginx builds do not all ship with Brotli support. Check your package or module set before adding Brotli directives.

Connection Handling and Keep-Alive

The keepalive_timeout directive controls how long an idle client connection stays open. Reusing a connection avoids extra TCP and TLS handshakes, but idle connections still consume resources.

http {
    # ...
    keepalive_timeout 65;
    keepalive_requests 1000;
    # ...
}

keepalive_timeout 65;: Sets the keep-alive timeout to 65 seconds.
keepalive_requests 1000;: Sets the maximum number of requests that can be made over a single keep-alive connection.

For APIs with many short requests, keep-alive helps. For a small server with many idle clients, a shorter timeout may be better.

Buffering and Request Size Limits

Nginx uses buffers for client bodies and proxied responses. Defaults are fine for many sites, but upload-heavy apps and large upstream headers may need explicit settings.

http {
    # ...
    client_body_buffer_size 10K;
    client_max_body_size 8M;
    proxy_buffers 8 16k;
    proxy_buffer_size 16k;
    proxy_connect_timeout 60;
    proxy_send_timeout 60;
    proxy_read_timeout 60;
    # ...
}

client_body_buffer_size: Size of the buffer used for reading the client request body.
client_max_body_size: Maximum allowed size of the client request body.
proxy_buffers, proxy_buffer_size: Control buffering when Nginx acts as a proxy.

Avoid copying buffer snippets blindly. If you see upstream sent too big header, investigate upstream headers before raising proxy_buffer_size. If uploads fail with 413 Request Entity Too Large, set client_max_body_size to the size your app actually supports.

TLS Optimization

For HTTPS sites, TLS settings affect both latency and security.

Session resumption: Use a session cache to speed up repeat connections.

ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
ssl_session_tickets off;

TLS versions: Enable TLS 1.2 and TLS 1.3 unless your compatibility requirements say otherwise.
OCSP stapling: Can reduce certificate validation round trips when your certificate chain supports it.
```
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
```

Static File Serving

Nginx is strong at serving static files. These directives are common in the http block:

sendfile: Lets the kernel copy file data directly to the socket on supported systems.
```
sendfile on;
```
tcp_nopush and tcp_nodelay: Tune packet sending behavior for common HTTP workloads.
```
tcp_nopush on;
tcp_nodelay on;
```

Monitoring and Testing

After each change, test and compare. Useful tools include:

Nginx stub_status: Active connections, accepted connections, handled connections, and requests.
top/htop: CPU and memory pressure.
iostat: Disk I/O.
WebPageTest or PageSpeed Insights: Browser-side performance.
wrk, ab, or hey: Local load testing against controlled endpoints.

Keep a copy of the previous config, run sudo nginx -t, reload, and compare latency, error rate, CPU, and upstream response time. The best Nginx performance optimization is the one your measurements can prove.

Practical Takeaway

Start with measurement, then fix the biggest bottleneck first. For most websites, that means setting sane worker limits, adding browser caching for static assets, enabling gzip, caching safe upstream responses, and watching logs after every reload.