What Time to First Byte tells you
Time to First Byte, or TTFB, describes how long it takes for the browser to receive the first byte of an HTTP response. For a page navigation, the interval can include redirects, connection setup, the trip to the server, server-side processing, and the trip back. It does not tell you how long the full response takes to download or how long the page takes to render.
A high TTFB is a useful clue, not a diagnosis. A page may be slow because the application spends time building HTML, but the same symptom can appear when a visitor is far from the server or must establish a new connection. Conversely, a low TTFB does not guarantee a fast page if large files or expensive browser work follow. Begin by identifying which request you are measuring: the main document, an API call, or a static asset.
Measure the same request under repeatable conditions
Open your browser’s developer tools, load the page, and inspect the Network waterfall. Select the main document request and look at its timing breakdown, status code, response headers, and any redirects. Repeat the test several times. One unusually slow load may reflect a temporary connection problem rather than the page’s usual behavior.
Compare a first visit with a repeat visit. A first visit may need DNS lookup and a new connection; a repeat visit may reuse a connection or receive a cached response. Record whether the browser cache is enabled, whether you are signed in, and which URL you requested. Changing those conditions between tests can make a real difference look like an improvement or regression.
The Navigation Timing API offers another view of a page load. For the navigation entry, the difference between responseStart and startTime represents the time from navigation start until the first response byte. Browser tools may also show a separate “waiting” phase for an individual request. These are related but not identical measurements: the broader navigation interval can include work that occurs before the request is sent.
Use the waterfall to locate the delay
Start before the request reaches the application. A chain of redirects adds trips before the final page can respond. DNS, connection, and TLS phases may stand out on a cold load, especially when several hostnames are involved. If these phases dominate, optimizing a database query is unlikely to change the measured result much.
Next, examine the time between sending the request and receiving the first byte. This interval includes network travel as well as work at the destination, so a long wait alone cannot prove the server is slow. Compare results from different network locations if you can test them consistently. A request that is quick near the server but slower farther away points toward distance or routing as a possible contributor.
Compare similar requests on the same connection. If one uncached HTML page waits much longer than a static file, investigate how that page is generated. If many requests to the same origin show similar delays, look for a shared dependency or infrastructure bottleneck. A cache hit and a cache miss may also behave very differently; check cache-related response headers rather than assuming every request follows the same path.
Trace slow work inside the application
When the delay appears tied to a dynamic response, break server processing into steps. Measure how long routing, authentication, database queries, calls to other services, and template rendering take. If your platform supports timing information in response headers, it can help connect browser observations with server-side measurements. Logs and traces should use request identifiers where possible so you can match a slow browser request to the work that produced it.
Look for patterns before changing code. Is the response slow only for signed-in users, large search results, or pages with particular data? Does it improve after a repeat request? These comparisons can reveal an expensive query, a dependency that sometimes responds slowly, or work that could be cached. Avoid treating a fast local development response as proof that the deployed path is fast; the data, dependencies, and network path may differ.
Choose a fix, then verify it
Match the intervention to the measured cause. Remove unnecessary redirects when they add trips. For expensive server work, consider simplifying queries, reducing sequential calls to dependencies, or caching responses where the content and access rules allow it. For content that can be served closer to visitors, an appropriate edge cache may reduce both server work and travel time. Each option has trade-offs: a cache needs a plan for freshness, and personalized pages need careful handling.
After a change, measure the same URL under the same conditions used for the baseline. Check both cold and repeat visits, and inspect the status code and response content to ensure the faster result is still the right result. Finally, look beyond TTFB. If the first byte arrives sooner but the page remains slow to use, the next bottleneck may be download size, rendering, or browser-side work.
