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

  1. Timing Field Inspector

    Fetch a set of resources and read their PerformanceResourceTiming entries in real time. The inspector surfaces workerMatchedRouterSource and workerFinalRouterSource alongside the classic timing metrics so you can see what Chrome 151 reports for each request.

  2. Router Source Values Explorer

    Interactive reference for every possible value of workerMatchedRouterSource and workerFinalRouterSource: what each means, when it appears, and how the matched and final sources can diverge when a primary source falls back.

  3. Router Timing Dashboard

    Fetch a batch of real resources and inspect every PerformanceResourceTiming entry 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.

  4. 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 watch matchedRouterSource diverge from finalRouterSource on a live timeline.

  5. 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.

  6. Live Echo Observer

    Fetch a real delayed echo route, collect PerformanceResourceTiming entries, and compare the Chrome 151 router fields with duration and Server-Timing values. Useful as a drop-in RUM probe pattern.

  7. 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 workerMatchedRouterSource and workerFinalRouterSource would carry. Click any row to see the routing logic explained.

  8. Production Checklist

    10 live production-readiness checks: API availability, field presence on the prototype, PerformanceObserver setup, 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

references

implementation reference

Need the exact API surface, compatibility boundaries, errors, lifecycle, and source links? Read the matching gendn reference ↗