In-flight Resource Requests

TPAC Oct 2018

npm@chromium.org

​

​

What do we want to solve?

We want to allow web developers to receive information about resource requests that have not been completed.

Sample use cases:

• Allow development of network quiescence signals for SPAs.
• Develop metrics that are based on network activity.
• Busy indicator widget that will spin during important network activity.

Goals of this presentation

• Arrive to consensus on a plan to spec the much needed API for in-flight resource requests.
• Ideally favor simpler plans to expose this API sooner rather than later.

I’ll present a proposed plan and some alternatives considered. Then we can agree on the best choice. Downsides of each proposal will be highlighted.

How do we propose solving this?

We propose adding a ResourceTimingUpdate interface that notifies when attributes have been computed.

• Only attributes that have reached their final state are notified.
• For now we only have updates at the beginning and end of a resource request.
• This model could expose more information once redirects are considered differently.

How will this look like in IDL?

interface ResourceTimingUpdate : PerformanceResourceTiming {

// “resourceUpdate”

readonly attribute DOMString entryType;

// All other inherited values are null before reaching their final state, then the final // value once they reach the final state.

� // List of strings with the names of attributes that have reached their final state.� readonly attribute sequence<DOMString> attributesUpdated;

}

• Not (yet) integrated with Fetch.
• PerformanceObserver is meant to deliver entries async, whereas some use cases would benefit from sync delivery (for example, busy widget indicator)..

Alternative 1: Modify PerformanceResourceTiming

One alternative is to modify the dispatch logic of PerformanceResourceTiming so that in-flight resource requests are also exposed.

• Not backwards compatible
• Can be confusing for current users

Alternative 2: event listeners for requests and responses

Another alternative is to have event listeners that would trigger callbacks whenever a request begins and whenever a response has been received.

• Would encourage early registration of event listeners
• Does not support buffering

Alternative 3: Create a FetchObserver

To better integrate with Fetch, we could create a FetchObserver that observes resource request updates.

• Should not receive a FetchEvent (defined by ServiceWorker spec) because those allow modifying the fetch.
• Could receive Request/Response objects plus timing information.
• This feels like we’re just replicating PerformanceObserver for this particular use case.

Discussion Time!