-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal: Network Idle Callback #4567
Comments
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. |
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. |
Apologies for my latency here :/ |
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 w3c/resource-timing#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. |
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
downlink
property gives an estimation of the effective bandwidth, though I don't think the value is updated near real time.Use cases
DOMContentLoaded
andonLoad
aren't called for route changes, and hence as a programmatic substitute for load low-priority resources.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 –Other usage examples
With
requestIdleCallback
Fire analytics when both CPU and network are free–
Prior Art
The text was updated successfully, but these errors were encountered: