Time to First Byte is a web performance metric that measures the time from a browser requesting a resource until it receives the first byte of the response. It shows how quickly a server and network path begin delivering content. TTFB is useful for diagnosing backend, hosting, caching, and connection delays, but it does not measure the complete page-load experience.
Time to First Byte
What Is Time to First Byte?
Time to First Byte, or TTFB, is the time between a browser requesting a resource and receiving the first byte of its response. It measures how quickly the network and server begin sending data, not how long a page takes to load or become interactive. MDN’s TTFB reference describes it as a responsiveness measure for web resources.
How TTFB Works
TTFB is the first-byte arrival time minus the measurement start point. Tools can use different start points, so compare results from the same method.
- The browser follows redirects and resolves the domain through DNS.
- It establishes a connection and, for HTTPS, negotiates TLS encryption.
- The request reaches the CDN edge or origin server.
- The server checks caches, runs code, queries data, and prepares a response.
- The first response byte returns to the browser, ending TTFB.
TTFB vs. Server Response Time and Page Load Time
These metrics overlap but answer different questions.
| Metric | What it captures |
|---|---|
| TTFB | Time until the response starts arriving, including connection and server delays. |
| Server response time | Backend work, such as application and database processing. |
| Largest Contentful Paint | When the main visible content appears to the user. |
| Total page load time | Completion of page resources, often after the first byte. |
A fast TTFB can still accompany a slow page when images, scripts, or rendering delay visible content.
Why Time to First Byte Matters
TTFB is a diagnostic signal, not a standalone SEO target. Google’s web performance guidance recommends examining the full request path.
- It can reveal a slow origin, cache miss, overloaded database, or poor routing.
- It helps teams find regressions after a release.
- It separates early delivery issues from rendering and asset-loading issues.
What Is a Good TTFB?
There is no universal good TTFB. Distance, connection reuse, caching, and dynamic content affect results. Compare the same route from similar locations and network conditions. A cached page near a visitor should usually respond sooner than a personalized page that queries several services. Focus on consistent improvement and unexpected changes, not one absolute number.
Why Is My TTFB So High?
A high reading shows delay before content starts, but not its exact cause.
- Redirects, distant servers, or slow connection and TLS setup add network delay.
- Uncached dynamic routes, slow database queries, third-party calls, and cold starts delay server work.
- Traffic spikes can make requests wait in a queue.
How to Measure and Improve TTFB
Use a repeatable workflow before changing infrastructure.
- Test key routes from several locations and note whether connections and caches are warm or cold.
- Inspect timing breakdowns to separate connection time from backend processing.
- Compare synthetic tests with real-user monitoring for location-specific issues.
- Trace slow backend work, then improve caching, CDN routing, database queries, or API design.
- Validate changes under comparable conditions and watch for regressions.
Time to First Byte in Emergent Apps
When shipping a full-stack product with Emergent’s AI web app builder, test TTFB on public pages and important application routes. Clear API-first design and monitoring API uptime help identify whether delay begins in the network, an API, or application code.
Start Building
on Emergent today
on Emergent today
Start Building
