networkTimeoutSeconds doesn't work the way it sounds

[wibblymat]

I've been adding toolbox to my own site, and playing with networkTimeoutSeconds, and I noticed that with a timeout of 1 second it still takes 3 seconds for the HTML to arrive when I simulate a GPRS connection.

The way I always imagined it was that if the page hasn't been completely downloaded inside the time limit then we try the cache.

However, this isn't true! A fetch will resolve as soon as the headers arrive. So the timeout is really only about time-to-first-byte.

I'm not sure what can really be done about it, but it should certainly be documented correctly.

[addyosmani]

I'm not sure what can really be done about it, but it should certainly be documented correctly.

Thanks Mat. My take is this is definitely something we should at minimum be documenting correctly but may defer solving better in sw-helpers.

The way I always imagined it was that if the page hasn't been completely downloaded inside the time limit then we try the cache.

@gauntface I wasn't able to find an equivalent for networkTimeoutSeconds implemented in sw-lib just yet. Have we already tackled this or another thing worth creating an issue for?

[jbmoelker]

Experienced the same and agree with @wibblymat. The current behaviour is more like a networkHeadStartSeconds as it's the time we allow the network before trying the cache. However I also expected networkTimeoutSeconds to be the time after which we reject the network. If there's also no cache entry, the developer could decide to fall back to an 'offline' page. Now the user could be hanging on forever just like before introduction of the service worker.