How to measure TTFB on Linux?

by Chris Texe | 16 October 2025 | Linux

What is TTFB

TTFB (Time To First Byte) is a measure of the time that elapses from when the browser sends a request to the moment the server returns the first byte of the response. In practice, it is the server’s “response time,” which determines how quickly the browser can begin rendering the page.

Why TTFB matters

– A shorter TTFB accelerates the start of loading and the first paint of content, which directly affects perceived speed and user satisfaction.
– A high TTFB often signals problems on the server or in the application (e.g., slow database queries, missing cache) before frontend assets even start downloading.

What makes up TTFB

– Network stage: DNS lookup, establishing the TCP connection and negotiating TLS, possible redirects.
– Server stage: receiving and handling the request (PHP/Node/etc.), application logic, database queries, generating the response, sending the first byte.
– Route and latency: distance between the user and the server/CDN and link quality.

How to interpret values

– Excellent: below ~200 ms (a common target for high‑performance sites).
– Acceptable: ~200–500 ms; above ~500–600 ms you should plan optimizations; >1000 ms usually calls for urgent diagnostics.

How to improve TTFB

– Server and hosting: faster CPU, up‑to‑date PHP with opcache, PHP‑FPM, HTTP/2/3, proper buffering and compression configuration.
– Caching: page cache at the application level, reverse proxy (e.g., Nginx/Apache with cache), object cache (Redis), full‑page cache on a CDN.
– Application: code profiling, reducing the number and cost of SQL queries, proper indexes in the database, removing unnecessary plugins/hooks, pre‑render for static pages.
– Network: CDN with POPs close to users, minimizing redirects, fast DNS, optimized TLS configuration (e.g., 0‑RTT/HTTP/3 where it makes sense).

How to measure in practice

– Use tools that let you select the test location (WebPageTest, Lighthouse/PageSpeed, curl with timing), because geography strongly influences results.
– Test different paths: homepage, critical landing pages and API endpoints; measure with and without cache to identify bottlenecks.
– Continuous monitoring: set alerts for TTFB spikes after deployments, traffic surges or infrastructure changes to react before UX and conversions suffer.

Most common causes of high TTFB

– Overloaded or slow server, missing opcache/non‑optimized FPM.
– No full‑page cache, dynamic rendering for every hit.
– Inefficient database queries, missing indexes, “N+1 queries.”
– Long redirect chains, slow DNS, no CDN or distant server location.

For WordPress/WooCommerce environments, quick wins include enabling full‑page cache (server/CDN), object cache (Redis), up‑to‑date PHP with opcache, removing heavy plugins, and optimizing queries and indexes in the database.

TTFB and SEO

TTFB affects SEO both indirectly and directly: a faster time to first byte speeds up initial rendering and shortens time to interaction, improving behavioral signals (lower bounce rate, longer time on page) and meeting search engines’ technical expectations regarding site speed.

How TTFB translates to ranking

– Speed is a ranking signal, and TTFB is an early component of the “initial server response time,” so lowering it helps meet performance criteria that search engines consider alongside content quality and links.
– Better TTFB improves early loading metrics, which can indirectly support Core Web Vitals (e.g., faster delivery of HTML facilitates earlier rendering of key elements).

Impact on user behavior

– A short TTFB reduces the “dead time” before the first paint, so users see a reaction from the site sooner and are less likely to abandon the visit.
– A faster start to loading promotes higher conversions and better engagement, which over time supports organic visibility.

Where TTFB helps most

– Dynamic sites (e.g., stores, offer finders) benefit from low TTFB because it shortens the time to generate the first response and indexable “above the fold.”
– International sites see greater gains after implementing a CDN and caching because POP proximity and edge caching significantly lower TTFB across regions.

Practical thresholds and interpretation

– Aim for TTFB below roughly 200 ms for key URLs; 200–500 ms is usually acceptable but worth optimizing; above 500–600 ms risks worsening UX and behavioral signals.
– Measure per location and per page template (home, category, product, checkout), as geography and cache state significantly affect results.

How to lower TTFB for SEO

– Infrastructure: performant hosting, HTTP/2/3, up‑to‑date PHP with opcache, faster storage, proper PHP‑FPM and database configuration.
– Caching and network: full‑page cache, CDN with edge cache, object cache (Redis), fewer redirects, fast DNS and optimized TLS.
– Application: query profiling, SQL indexes, eliminating N+1, limiting heavy plugins/hooks, prerendering critical pages.

For WordPress/WooCommerce

– Enable page cache (server/CDN), use Redis for object cache, update PHP and theme/plugins, optimize queries and indexes, and shorten redirect chains.
– Test TTFB in cold/warm cache states and from locations closest to your users to make SEO‑relevant decisions.