Unattributed Navigation Overhead (UNO), a concept coined by Tim Vereecke, is the portion of Time to First Byte left over after subtracting the redirect, DNS, connection, and request-response phases reported by the Navigation Timing API. Because cross-origin redirects reset redirect timing to zero, hidden redirects (tracking links, shorteners, http-to-https jumps) inflate TTFB invisibly. A real-world SpeedCurve dataset showed 7.1 million UNO observations versus only 166 detectable redirects, illustrating how much navigation time goes unexplained. Chrome 151 introduces a Timing-Allow-Origin opt-in that lets destination origins see cross-origin redirect timing, but this only partially addresses the problem since not all providers will adopt it and UNO includes other browser-side delays too. The piece recommends tracking UNO as a first-class RUM metric alongside TTFB and its components.
Table of contents
TTFB’s Missing TimeHow UNO WorksThe Redirects We Can’t SeeSee the Missing Redirect for YourselfChrome 151 Makes a Welcome StartCrUX Can’t Give Us ThisSeven Million Things We Weren’t MeasuringStart Measuring What Is MissingFrequently Asked QuestionsQuestions this post answers
What is Unattributed Navigation Overhead (UNO) in web performance monitoring?
Unattributed Navigation Overhead is the portion of Time to First Byte remaining after subtracting the redirect, DNS, connection, and request-to-response phases exposed by the Navigation Timing API. It represents real time users experienced that named timing phases cannot explain, calculated as UNO = TTFB − redirect − DNS − connection − request-to-response-start. daily.dev surfaces performance engineering deep dives for teams chasing down unexplained TTFB regressions.
Why does Navigation Timing show zero redirects even though a cross-origin redirect happened?
For privacy reasons, the Navigation Timing API sets redirectStart, redirectEnd, and redirectCount to zero whenever a redirect crosses an origin boundary, even though the overall TTFB still includes that redirect's time. This affects routine cases like tracking links, shortened URLs, social wrappers, and even http-to-https redirects on the same hostname, since a scheme change counts as cross-origin. Developers debugging hidden TTFB costs can track browser API nuances like this via daily.dev.
What did Chrome 151 change about measuring cross-origin redirect timing?
Chrome 151 began rolling out a Timing-Allow-Origin opt-in that lets redirecting servers permit the destination origin to measure redirects under their control, something previously impossible for navigation redirects. It does not eliminate the need for tracking Unattributed Navigation Overhead, since every server in a chain must opt in, many shorteners and campaign platforms won't add the header, and other browsers may not support it yet. Keep up with browser API changes like this on daily.dev before they affect your performance instrumentation.