Frontend Beauty
ESC

Type to search the knowledge base.

Navigation Timing API

PerformanceNavigationTiming phases from startTime to loadEventEnd for document load diagnostics.

advanced3 min read
  • browser
  • navigation-timing
  • performance
  • ttfb

Navigation Timing explains how long the document navigation took: DNS, connect, request, response, DOM events, load. It is the structured replacement for the old performance.timing mess, exposed as PerformanceNavigationTiming.

Docs: MDN Navigation Timing, Navigation Timing Level 2.

Get the entry

const [nav] = performance.getEntriesByType('navigation');
// or
const nav = performance.getEntriesByType('navigation')[0];

console.log({
  type: nav.type, // navigate | reload | back_forward | prerender
  ttfb: nav.responseStart - nav.requestStart,
  domContentLoaded: nav.domContentLoadedEventEnd - nav.startTime,
  load: nav.loadEventEnd - nav.startTime,
  transferSize: nav.transferSize,
});

Also available via PerformanceObserver with type: 'navigation'.

Useful timestamps (relative to startTime)

Field Milestone
redirectStart/End Redirects
workerStart Service worker startup
domainLookupStart/End DNS
connectStart/End TCP
secureConnectionStart TLS
requestStart Request sent
responseStart First byte (TTFB-related)
responseEnd Body finished
domInteractive DOM ready enough
domContentLoadedEventEnd DCL
loadEventEnd window load

Exact formulas for TTFB vary slightly by tool; many use responseStart - startTime or from requestStart. Align with your RUM vendor. See TTFB and Server-Timing.

Cache signals

nav.transferSize === 0 && nav.decodedBodySize > 0; // often cache / SW
nav.nextHopProtocol; // h2, h3, http/1.1

Interpret carefully with service workers — Resource Timing for subresources.

What it does not measure

  • SPA client-side route changes (no new navigation entry type for soft navs unless using newer soft-nav experiments)
  • INP / interaction latency
  • Continuous CLS

Use Navigation Timing for full document loads, not for every React route.

Server-Timing bridge

Server-Timing: db;dur=12, render;dur=40
nav.serverTiming; // [{ name, duration, description }]

Breaks TTFB into backend phases when the origin sends the header.

Interview out-loud

“PerformanceNavigationTiming gives document phases from DNS through loadEventEnd. I compute TTFB and DCL/load, check type and nextHopProtocol, and use Server-Timing for backend splits. Soft SPA navigations need other instrumentation.”

Redirect chains

If redirectCount > 0, sum redirect time and fix www/apex/http→https chains at the edge. Each redirect adds RTT before HTML starts. Frontend “perf projects” often start here when TTFB looks mysteriously high only on marketing entry URLs.

Field aggregation tips

Store type, nextHopProtocol, and a coarse TTFB bucket per navigation. Alert when p75 TTFB jumps after a deploy or CDN change. Compare back_forward navigations separately — they may be bfcache restores with near-zero network time and should not be averaged into cold-load SLOs. For SPA shells, attach a soft-navigation id for client route changes because Navigation Timing will not reset.

Further depth

Teams often under-invest in this topic until an incident or CWV regression. Schedule a one-hour drill: reproduce the failure mode in DevTools, list the top three mitigations for your stack, and file tickets with owners. Revisit after the next major feature that touches networking, rendering, auth, or third parties — those are the moments regressions land. Keep primary documentation links in the runbook so on-call is not searching chat history at 2am.

Concrete artifacts to leave behind: a short architecture note, a CI assertion or header snapshot, and a dashboard panel (lab or field) that would have caught the last bug. Teaching the rest of the team the mental model matters as much as the one-line fix.

Further reading

Related guides