v140 · service worker routing
What going through the handler costs
Three files with identical contents, in the same directory, differing only in which router source their path is bound to. Fetch each one and the difference in time is the cost of reaching the fetch handler — which is the cost this optimization exists to avoid.
Fetch each lane
| lane | router source | median ms | served by | bytes |
|---|---|---|---|---|
| Not measured yet. | ||||
The "served by" column is read from a response header the fetch handler sets. It is how this page knows the router did what it was asked: a lane routed to network has no such header, because the handler never ran.
What is actually being measured
The fetch handler in this demo waits a fixed time before forwarding the request, so the gap between the lanes is dominated by a delay we chose rather than by the real cost of waking a worker. That is deliberate: a real bootstrap cost is small, noisy and different on every machine, and a demo built on it would show nothing repeatable.
What the shape tells you is real. A request routed to the network does not reach the worker at all, so nothing the worker does can slow it down — no bootstrap, no handler, no queueing behind other work. That is the property the optimization is buying, and the fixed delay just makes it visible.