expose Resource Timing API information for web worker XHRs

[sbma44]

Motivation

Characterizing performance as resources are fetched is useful for a variety of purposes. Although some of GL JS's resource-fetching can already be scrutinized via the Resource Timing API, requests made by web workers, including tile fetches, are monitored but their measurements remain stranded in the worker's DedicatedWorkerGlobalScope.

Design Alternatives

Measuring request time is possible using existing GL JS events, but not with the level of specificity available via the Resource Timing API (cf https://developer.mozilla.org/en-US/docs/Web/API/PerformanceResourceTiming).

Design

An options.collectTiming (or similar) boolean is passed when the Map object is instantiated. If true, MapDataEvents received by event listeners should include the PerformanceEntry object associated with each XHR, as appropriate (e.g. when isSourceLoaded is true). My read of the code indicates that this property will need to be passed down to web workers, and when true, workers will collect and pass back PerformanceEntrys to WorkerTileCallback (as an additional property alongside rawTileData, I think?).

I have been examining this problem from a vector-tile-fetching perspective; apologies if there are other resource types that should be included here that I haven't considered. At a glance it appears that repeating this pattern across worker-fetched resource types shouldn't be too bad.

Mock-Up

Developers will be able to enable this flag and collect timing information from event callbacks.
End users should not notice any difference.

Concepts

The Resource Timing API is widely used and supported browser API, so many resources already exist to familiarize developers with the relevant concepts. Updating documentation to make users aware of this option and to explain why they can't access tile timings from the application's scope will be useful.

Implementation

See above for Javascript implementation proposal.

I suspect that C++ idioms for measuring network performance are distinct and should be respected. Sharing property names across implementations might be nice. I don't see an immediate need for implementing in other Mapbox GL libraries, though. I don't see any broad impacts on the Mapbox GL ecosystem.

[sbma44]

Noting briefly that thanks to spirit guidance from @anandthakker I've got a working prototype -- adding support for GeoJSON sources and tests now, should have something for you all in a day or two.

[mollymerp]

closed in #5991 – thanks @sbma44