When evaluating website performance, developers often examine Time to First Byte (TTFB) and document load duration. Standardized browser performance specifications define precise timestamps for these milestones. Understanding how these metrics are defined in public specifications clarifies what each value measures during document navigation.
What TTFB Measures
According to web.dev’s documentation on Time to First Byte, TTFB measures the elapsed time between navigation start (startTime) and when the first byte of a response begins to arrive at the client (responseStart). Because TTFB occurs early in navigation, web.dev notes that it precedes user-centric rendering metrics such as First Contentful Paint (FCP) and Largest Contentful Paint (LCP).
web.dev identifies TTFB as the sum of several initial request phases:
- Redirect time (if applicable)
- Service worker startup time (if applicable)
- DNS lookup
- Connection and TLS negotiation
- Request transmission, up until the arrival of the first byte of the response
web.dev notes that reducing connection setup latency and backend delays can lower TTFB. To support a good FCP at the 75th percentile of users, web.dev identifies a TTFB of 0.8 seconds or less as a good score, while values greater than 1.8 seconds are categorized as poor.
Document Navigation Timings in PerformanceNavigationTiming
The W3C Navigation Timing specification, as documented in MDN’s PerformanceNavigationTiming reference, defines timestamps to record document navigation events. On the PerformanceNavigationTiming interface, overall navigation duration is exposed via the duration property, which is calculated as the difference between loadEventEnd and startTime (where startTime returns 0).
MDN documents the following standardized instance properties:
startTime: Returns aDOMHighResTimeStampwith a value of 0.domInteractive: The time immediately before the user agent sets the document’sreadyStateto"interactive".domContentLoadedEventStart: The time immediately before the document’sDOMContentLoadedevent handler starts.domContentLoadedEventEnd: The time immediately after the document’sDOMContentLoadedevent handler completes.domComplete: The time immediately before the user agent sets the document’sreadyStateto"complete".loadEventStart: The time immediately before the document’sloadevent handler starts.loadEventEnd: The time immediately after the document’sloadevent handler completes.duration: The difference betweenloadEventEndandstartTime.
Documented Differences Between TTFB and Navigation Duration
TTFB and navigation duration cover different spans within the browser performance timeline. The following table summarizes their documented boundaries and criteria based on the visible specifications:
| Metric | Standard API Span | Documented Contributing Components | Documented Thresholds / Scope |
|---|---|---|---|
| Time to First Byte (TTFB) | startTime to responseStart |
Redirects, service worker startup, DNS lookup, TLS/connection negotiation, and initial request transmission | Good: ≤ 0.8s; Poor: > 1.8s (per web.dev) |
| Document Navigation Duration | startTime to loadEventEnd |
The entire navigation event lifecycle ending when the window’s load event handler completes |
Calculated as loadEventEnd - startTime (per MDN) |
Early Hints and Response Start Nuances
web.dev notes that HTTP 103 Early Hints impacts how TTFB is measured because the 103 Early Hints response counts as the first bytes, which records at responseStart. To measure the arrival of the final document response headers (typically an HTTP 200 response), modern implementations include an additional timing entry called finalResponseHeadersStart.
web.dev also notes that some servers perform early flushing of the response before the main body is ready—such as sending HTTP headers or the <head> element early. Because these early flushes register at responseStart, comparing TTFB across different platforms or tools requires knowing whether a given tool records the initial informational byte or the final document response.
Measuring TTFB in JavaScript
To measure navigation TTFB directly in the browser using the Navigation Timing API, web.dev provides the following PerformanceObserver example:
new PerformanceObserver((entryList) => {
const [pageNav] = entryList.getEntriesByType('navigation');
console.log(`TTFB: ${pageNav.responseStart}`);
}).observe({ type: 'navigation', buffered: true });
web.dev also documents that TTFB can be recorded using the web-vitals JavaScript library:
import { onTTFB } from 'web-vitals';
// Measure and log TTFB as soon as it's available.
onTTFB(console.log);
The visible excerpt does not specify specific version numbers, browser support matrices, or environment compatibility requirements for the web-vitals package import.
For subresources, web.dev documents that TTFB can be observed using entryList.getEntries() with { type: 'resource', buffered: true }. In that context, a subresource may return a responseStart value of 0 if cached or if a cross-origin resource is served without a Timing-Allow-Origin header.
Research Method and Limitations
This technical explainer was prepared strictly from the supplied public documentation excerpts from web.dev and MDN Web Docs (PerformanceNavigationTiming). It does not rely on unpublished browser internals, private benchmarks, or independent laboratory measurements. A material limitation is that the supplied third-party competitor excerpt (Kinsta) was heavily truncated, preventing independent verification of broader industry claims, testing ranges, or commercial hosting practices. Additionally, the supplied web.dev documentation does not document version numbers or compatibility constraints for the web-vitals library sample, and MDN does not define causal workload attributions beyond the specified lifecycle timestamps.
Text version of the diagrams
- TTFB vs Navigation Duration: TTFB — startTime to responseStart; Response Start — First response byte arrives; Navigation Duration — startTime to loadEventEnd
- Which Response Start?: Early Bytes — 103 or flushed headers; responseStart — First bytes used by TTFB; Final Headers — finalResponseHeadersStart
