Closed yoavweiss closed 5 years ago
We've had some confusion about RT data from our RUM customers around range requests, from sites that are fetching videos or PDF.js range-fetching parts of a PDF. Mostly they just needed to add TAO so they could see the transfer sizes for each fetch, to understand which ones were fetching the full video or just parts.
That being said I think it would be nice to get insight into the range bytes, so one could understand which order the file is being completed (e.g. if the first parts aren't being delivered first, they may be blocking the view)
I think this is another instance of https://github.com/w3c/resource-timing/issues/21. As in, we should investigate range requests as part of that issue / merge this one into 21, and treat it as L3 exploration. WDYT?
Makes sense!
Some loading patterns may trigger multiple requests to fetch a single resource, using range requests to fetch different chunks of the resource at different times.
That's a pattern we already see with videos, and are likely to see more with image lazy loading. Developers can already see the length of the downloaded resource (using
transferSize
) for resources that pass the timing allow check, but I'm not sure that's enough.Should the range of the request be somehow surfaced to the ResourceTiming entry?