Skip to content
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

Resource Timing and range requests #205

Closed
yoavweiss opened this issue Mar 29, 2019 · 3 comments
Closed

Resource Timing and range requests #205

yoavweiss opened this issue Mar 29, 2019 · 3 comments

Comments

@yoavweiss
Copy link
Contributor

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?

@nicjansma
Copy link
Contributor

nicjansma commented Apr 11, 2019

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)

@igrigorik
Copy link
Member

I think this is another instance of #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?

@yoavweiss
Copy link
Contributor Author

Makes sense!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants