When TTFB is 900 ms and the application code has already been profiled, the remaining time is usually not in the application at all. It is in the handoff between nginx and whatever process is listening on a local port \u2014 a worker that was busy, a connection that had to be re-established, or a response that nginx buffered to disk before sending a single byte to the client. The application log reports 30 ms of work and the browser measures 900 ms, and both are correct.<\/p>\n\n\n\n
This article covers the nginx side of that boundary for application servers reached over FastCGI, HTTP\/1.1 on localhost, or a Unix socket. The settings below are the ones that change TTFB measurably; the goal is to stop guessing which of them matters by measuring the split between upstream wait time and connection setup time.<\/p>\n\n\n\n
nginx can log the exact time spent waiting for the upstream separately from the time spent serving the client. Enable a timing-oriented log format before changing any configuration, otherwise you are tuning against intuition.<\/p>\n\n\n\n
log_format timing '$request $status '\n 'urt=$upstream_response_time uct=$upstream_connect_time '\n 'uht=$upstream_header_time rt=$request_time '\n 'cs=$upstream_cache_status';\naccess_log \/var\/log\/nginx\/timing.log timing;<\/code><\/pre>\n\n\n\nCompare uht<\/code> (time to first byte from the upstream’s perspective) with urt<\/code> (time for the upstream to finish the whole body). When uht<\/code> is close to urt<\/code>, the application is slow before it writes anything: queueing, connection setup, or a blocking call in the request path. When urt<\/code> is far larger, the response body is being generated slowly while headers are already out, which is a different fix entirely.<\/p>\n\n\n\nReuse Upstream Connections Instead of Dialling Per Request<\/h2>\n\n\n\n
By default, nginx opens a new connection to the upstream for every proxied request. On loopback that costs a TCP handshake and, more importantly, forces the application server to spawn a fresh worker or accept a new socket on each request. Keepalive to the upstream removes both, and on a small instance it is usually worth 20 to 60 ms of TTFB on the p95.<\/p>\n\n\n\n
upstream app_backend {\n server unix:\/run\/app\/gunicorn.sock;\n keepalive 32;\n keepalive_requests 1000;\n keepalive_timeout 60s;\n}\n\nlocation \/ {\n proxy_http_version 1.1;\n proxy_set_header Connection \"\";\n proxy_pass http:\/\/app_backend;\n}<\/code><\/pre>\n\n\n\nThe Connection \"\"<\/code> line is mandatory: without it nginx sends Connection: close<\/code> and keepalive silently does nothing, which is one of the most common misconfigurations in copy-pasted upstream blocks. keepalive 32<\/code> is a per-worker pool, so with four nginx workers you get up to 128 idle upstream connections; on a 1 GB instance that is fine, on a 512 MB one it is worth halving.<\/p>\n\n\n\nKill Nagle and Delayed ACK With TCP_NODELAY<\/h2>\n\n\n\n
Loopback is not free of Nagle’s algorithm. Small header-then-body writes from the application server can be held for up to 40 ms waiting for an acknowledgement, which is exactly the kind of latency that shows up as p99 TTFB with a healthy median.<\/p>\n\n\n\n
location \/ {\n proxy_set_header Connection \"\";\n tcp_nodelay on;\n proxy_socket_keepalive on;\n}<\/code><\/pre>\n\n\n\ntcp_nodelay<\/code> is on by default in modern nginx, but it applies to the client side; the upstream side honours the kernel’s per-socket behaviour. If you control the application server, enable its own TCP_NODELAY. If you do not, a Unix socket bypasses TCP entirely and removes the question \u2014 which is often the single best change for a local app server.<\/p>\n\n\n\nClose the Connections You No Longer Need<\/h2>\n\n\n\n
A tuning guide that only adds settings is incomplete; two defaults actively add latency on small instances. proxy_connect_timeout<\/code> and proxy_read_timeout<\/code> default to 60 seconds, meaning a hung worker ties up a client connection and a worker for a full minute. And keepalive_timeout<\/code> for clients at 75 seconds holds file descriptors far longer than most sites need.<\/p>\n\n\n\nkeepalive_timeout 20s;\nkeepalive_requests 500;\n\nproxy_connect_timeout 3s;\nproxy_send_timeout 15s;\nproxy_read_timeout 20s;<\/code><\/pre>\n\n\n\nShorter timeouts convert a stall into a fast 502, which is visible in monitoring, rather than an invisible slow request that never reaches your error budget. That trade is almost always correct for application servers, which should answer quickly or fail loudly. A single hung worker then produces one orphaned connection instead of a traffic queue behind it.<\/p>\n\n\n\n
Stop Buffering Responses to Disk<\/h2>\n\n\n\n
nginx buffers upstream responses by default and spills to a temporary file once the buffer is full. For generated HTML in the tens of kilobytes this adds a write and a read on the same request path, and the file I\/O competes with everything else on the disk.<\/p>\n\n\n\n
proxy_buffering on;\nproxy_buffers 8 8k;\nproxy_buffer_size 8k;\nproxy_busy_buffers_size 16k;\nproxy_max_temp_file_size 0; # never spill to disk\n\n# streaming endpoints only:\n# proxy_buffering off;<\/code><\/pre>\n\n\n\nDisabling buffering entirely is the wrong lever for normal page requests: it makes nginx forward bytes as soon as they arrive, so a slow application holds a client connection longer and the client sees a partially rendered page. Keep buffering on, keep it in memory, and reserve proxy_buffering off<\/code> for server-sent events and long-polling endpoints in their own location<\/code> block.<\/p>\n\n\n\nFix the Compression and Static Path First<\/h2>\n\n\n\n
Before tuning the upstream handoff, confirm the request is not hitting an application server at all when it should be served from disk. A surprising share of slow TTFB reports trace to static assets being proxied through the app because a location<\/code> regex did not match.<\/p>\n\n\n\nlocation ~* \\.(css|js|woff2|png|jpg|svg)$ {\n root \/var\/www\/app\/static;\n expires 30d;\n access_log off;\n try_files $uri =404;\n}\n\ngzip on;\ngzip_types text\/css application\/javascript application\/json;\ngzip_min_length 1024;<\/code><\/pre>\n\n\n\nCompression should be applied to text responses, never to already-compressed media, and gzip_min_length<\/code> prevents spending CPU on tiny responses where the header overhead exceeds the saving. On a CPU-constrained instance, compressing responses above 1 KB only, at a modest level, is the right balance. If the stack is WordPress, the interaction between this layer and the application cache is the larger factor, and it is covered in cloud VPS benefits for cache-heavy workloads<\/a>.<\/p>\n\n\n\nValidate the Change With a Load Generator, Not a Browser<\/h2>\n\n\n\n
Browser timing includes DNS, TLS and client-side work, all of which blur the server-side picture. Use a fixed-concurrency generator against a specific URL and compare p50 and p95 across configuration variants, changing one setting at a time.<\/p>\n\n\n\n
wrk -t2 -c20 -d30s https:\/\/example.com\/\ncurl -s -o \/dev\/null -w '%{time_starttransfer}\\n' https:\/\/example.com\/\n# then read up= values from the timing log for the same window<\/code><\/pre>\n\n\n