cURL is an exceptionally powerful tool for performance testing, benchmarking, and debugging network latency issues. The -w flag (or --write-out) allows you to define a custom output format string that can include a comprehensive range of variables representing different stages of the HTTP transfer. These variables provide granular visibility into every phase of the request lifecycle, from DNS lookup through final byte received. The write-out feature transforms cURL from a simple data transfer tool into a sophisticated network diagnostics instrument. You can construct format strings with multiple variables, newlines ( ), tabs ( ), and literal text to create readable performance reports.

Critical Timing Variables Explained:

• time_namelookup: Represents the time in seconds from the start of the cURL operation until DNS name resolution (lookup) for the target host was completed. This measures how long it takes to translate a hostname (like example.com) into an IP address. High values (typically over 0.1s) can indicate DNS server issues, network problems reaching DNS servers, or DNS response delays. If your DNS is properly cached, this should be near zero on subsequent requests to the same domain.
• time_connect: Measures the time in seconds from the start until the TCP connection to the remote host (or proxy) was successfully established. This duration includes the TCP three-way handshake (SYN, SYN-ACK, ACK). High values suggest network latency, geographic distance from the server, network congestion, routing problems, or server-side connection throttling. This is purely network-layer timing and doesn't include any application protocol overhead.
• time_appconnect: For HTTPS connections, this is the time in seconds until the SSL/TLS handshake was completed and the secure connection was ready for application data. This includes certificate exchange, validation, and cipher negotiation. This timing is crucial for debugging HTTPS latency issues. A large gap between time_connect and time_appconnect indicates SSL/TLS handshake overhead, which can be significant for the first connection but should be much faster with session resumption on subsequent requests.
• time_starttransfer: Commonly known as Time To First Byte (TTFB), this measures the time in seconds from the start until the first byte of the response begins to be transferred from the server. This encompasses all previous stages (DNS, TCP connect, TLS handshake if HTTPS, sending the request) plus the server's processing time—how long the server takes to generate the response. TTFB is a critical performance metric for web applications. High TTFB (typically over 0.5-1s) can indicate slow server-side processing, inefficient database queries, overloaded servers, or application code performance issues. The difference between time_starttransfer and time_appconnect (or time_connect for HTTP) represents pure server processing and response time.
• time_total: The complete duration of the entire operation in seconds, from connection initiation to the final byte received and connection closure. This is useful for understanding end-to-end latency including download time for the response body.

Best Practices for Performance Measurement: When measuring pure performance metrics rather than retrieving actual content, it's standard practice to use -o /dev/null (or NUL on Windows, $null in PowerShell) to discard the response body, preventing it from being written to disk or displayed on screen. This ensures you're measuring network and server performance without I/O bottlenecks from writing large files. Combine this with -s (or --silent) to suppress the progress meter and other operational messages, ensuring only your custom formatted timing output is displayed. For comprehensive testing, also consider -L to follow redirects if applicable. Additional useful variables include size_download (bytes downloaded), speed_download (average download speed), http_code (HTTP status code), and url_effective (final URL after redirects). You can save your write-out format to a file and reference it with -w @format.txt for complex recurring measurements, making your performance testing reproducible and consistent.