Proposal: Network Idle Callback

pastelsky commented 5 years ago

Summary

The web lacks a programmatic way to detect network activity and schedule low priority or pre-emptive network tasks. I'd like to propose an API – networkIdleCallback (say), that would allow one to schedule tasks that execute when the network activity in the current browsing context falls below a certain threshold.

Existing APIs and how they compare

Resource Hints: Prefetching or preloading is limited to the loading of resources, and isn't easy to schedule or predict when the load is triggered.
Network Information API: More specifically, the downlink property gives an estimation of the effective bandwidth, though I don't think the value is updated near real time.

Use cases

Scheduling non-critical analytics to be flushed to the server at idle time.
In single page applications – where page lifecycle methods like DOMContentLoaded and onLoad aren't called for route changes, and hence as a programmatic substitute for load low-priority resources.
A companion to the Cache API – for preloading data and/or resources and saving them in the service worker cache when the host page is idle.

Possible API

A perhaps intuitive way to model this would be to emulate the requestIdleCallback API –

    const callbackId = 
     networkIdleCallback(() => {
       // load resources or execute action when network is idle
     }, { timeout: 1000 })

    cancelNetworkIdleCallback(callbackId)

Other usage examples

With requestIdleCallback

Fire analytics when both CPU and network are free– ```js function fireEvents(listOfEvents) { requestIdleCallback(() => { const normalizedEvents = someHeavyCompute(listOfEvents) networkIdleCallback(() => someEventFlusher(normalizedEvents), { timeout: 1000 } ) }, { timeout: 500 }) } ```

Prior Art

networkIdleCallback – A ponyfill I made for this proposed API sometime back that uses service workers to detect network idle state.
network-connection-class – A library for Android by facebook that gives a moving average of connection speed.

surma commented 5 years ago

I think you have a point here, but this is probably something you should post in the WICG to get consensus on usefulness and browser interest and also if you are overlapping with already existing efforts.

addyosmani commented 5 years ago

cc @yoavweiss as the WebPerf WG may be interested.

I have a use-case for approximating network idle for a library I'm working on (https://github.com/GoogleChromeLabs/quicklink). Today we're relying on requestIdleCallback() as a poor stop-gap (without network idle information) but otherwise suggest users rely on Service Workers for a solution using https://github.com/pastelsky/network-idle-callback.

My understanding is the last time network idle was discussed at TPAC, the consensus was to present a new proposal that would allow you to query an array with the list of pending resource requests, along with some extra information about each (like the type, etc.). The group didn't go with a callback because the most important use cases prefer immediate knowledge of the pending requests. Yoav may know more here.

yoavweiss commented 5 years ago

Apologies for my latency here :/ @npm1 has the details on our latest proposal on that front. Not sure about timelines for that tho.

npm1 commented 5 years ago

Yes, at TPAC no one objected to the array approach. However, after TPAC I presented that approach and there was no consensus because there are notification use cases; the minutes are here. I was asked to gather use cases, and I wrote a doc showing how the observer approach would satisfy the use cases. There is some discussion at https://github.com/w3c/resource-timing/issues/137. But I got no responses from other browser vendors and got busy with other work, so I have not followed up since then. This sounds like a good candidate for an API that could be developed with the users of the API and incubated in WICG. I don't see the Web Perf WG making any progress on it anytime soon without strong pressure from real-world usage.

whatwg / html