-
Notifications
You must be signed in to change notification settings - Fork 0
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
[LoAF] is blockingDuration needed? #8
Comments
The thing about inferring blockingDuration from scripts is that you can miss the following contributors to blocking:
I see a few alternative ways about this:
|
RE: 1 --I like that its a bit more interoperable with the Long Tasks api-- but it's also less flexible to evolve. I could imagine adding more to blockingTime than just one task. But maybe you general point is that exposing a "total blocking duration", without subtracting 50ms or including rendering time automatically, is easier to understand? RE 2: --Interesting. That makes some sense... On the other hand, today LoAF will already slice tasks at processingEnd whenever we know we don't need rendering (i.e. fallback to LongTask time). And so this proposal would be similar. Tasks which aren't immediately followed by rendering are "just tasks", and not really LoAFs, from the perspective of the "blocking" concept. So we'd have [Task] as distinct entry, then [Task] nested within LoAF but outside "blocking" time, and then [Task+Rendering]. If we believe that is the right way, then maybe we just split LoAF entries, and make LoAF.duration == blockingDuration? RE 3: -- I think I am mostly in this camp right now. I do think right now many pages will report long LoAFs which are due to render-throttling and may not be the "fault" of the page, but its also a true representation of UX. So it just comes down to how the data is interpreted... |
Some partners are finding |
The goals of
blockingDuration
I believe are twofold:However, I think it may be both redundant and inaccurate/incomplete.
Redundant:
LoAF already reports script attribution for tasks which are >5ms, and reports timestamps for rendering. Perhaps you can already define your own "good enough" blocking duration in terms of these values?
In practice, I find that I mostly see very near numbers, but occasionally am seeing a large divergence in ways I cannot easily spot from from metrics. Perhaps when no scripts are not reported to attribution? Or perhaps I am holding it wrong.
Inaccurate/incomplete:
It may not true that only a single longest task + rendering are the "shortest possible blocking duration". It may be that more than a single task must be dispatched before rendering. (Examples: Multiple event dispatch at equal priority; raf-aligned events; rAF callbacks...).
Perhaps
blockingDuration
is useful and could evolve into some "shortest possible path". Or perhaps "scripts" attribution could expose task priority, or some "blocking: true" field.The text was updated successfully, but these errors were encountered: