v151 · Performance · Resource Timing
Resource Timing: Service Worker Router timing fields
Chrome 151 adds workerMatchedRouterSource and workerFinalRouterSource to PerformanceResourceTiming. These fields expose which Service Worker Static Router rule was matched, and which source ultimately served the response — giving developers precise insight into the routing path of every intercepted resource.
concepts
-
Timing Field Inspector
Fetch a set of resources and read their
PerformanceResourceTimingentries in real time. The inspector surfacesworkerMatchedRouterSourceandworkerFinalRouterSourcealongside the classic timing metrics so you can see what Chrome 151 reports for each request. -
Router Source Values Explorer
Interactive reference for every possible value of
workerMatchedRouterSourceandworkerFinalRouterSource: what each means, when it appears, and how the matched and final sources can diverge when a primary source falls back. -
Router Timing Dashboard
Fetch a batch of real resources and inspect every
PerformanceResourceTimingentry for both new Chrome 151 fields side by side with classic duration metrics. Click any row to expand the full entry. Shows live feature detection of whether both fields are present in this browser. -
Race Strategy Visualizer
The most subtle router source —
race-network-and-fetch-handler— fires both paths and accepts whichever wins. Slide cache and network latencies, toggle cache-miss and offline, and watchmatchedRouterSourcediverge fromfinalRouterSourceon a live timeline. -
RUM Aggregator
A working RUM dashboard for the new fields. Generates a synthetic session (size, cache-miss rate, offline rate, 3G slow share), beacons each entry, and renders a p50/p95 + divergence summary. The exact dashboard you'd ship behind a
PerformanceObserver. -
Live Echo Observer
Fetch a real delayed echo route, collect
PerformanceResourceTimingentries, and compare the Chrome 151 router fields with duration andServer-Timingvalues. Useful as a drop-in RUM probe pattern. -
Waterfall Debugger
Simulates six routing scenarios — cold cache, warm cache, cache miss → network fallback, race (network wins), race (cache wins), and no SW — and annotates each resource's decision path using the values that
workerMatchedRouterSourceandworkerFinalRouterSourcewould carry. Click any row to see the routing logic explained. -
Production Checklist
10 live production-readiness checks: API availability, field presence on the prototype,
PerformanceObserversetup, secure context, ServiceWorker availability, feature-detection guard, buffered observer, and divergence handling. Each check runs in-browser and reports the minimum code change needed.
why it shipped
The Service Worker Static Router API (shipped in Chrome 123) lets service workers declare declarative routing rules — "serve this URL pattern from cache", "bypass the service worker for that origin". But developers had no way to observe which rule was hit at runtime, or whether the browser fell back to a different source when the matched one was unavailable. The new fields close that gap: workerMatchedRouterSource records which rule's source the browser selected, and workerFinalRouterSource records what actually served the bytes (which may differ if, say, the cache miss triggered a network fall-through). This is the same level of observability developers already have for cache vs. network via existing timing flags — now extended to cover the full router source taxonomy.
the two new fields
workerMatchedRouterSource— the source specified by the matched Static Router rule (e.g."cache","network","fetch-event","race-network-and-fetch-handler"). Empty string if no rule matched.workerFinalRouterSource— the source that actually served the response. May differ from the matched source if the primary source was unavailable and the browser fell through to a fallback.
references
implementation reference
Need the exact API surface, compatibility boundaries, errors, lifecycle, and source links? Read the matching gendn reference ↗