kAttributeLayoutBlocking annotation for request trace_events |
||
Issue descriptionLighthouse, Clovis, etc are building the a critical path model based on network and trace data. One important signal that we are currently inferring is if a request is layout blocking. This inference is imperfect, and it'd be MUCH better to get the truth straight from blink. The resource priorities CL (https://codereview.chromium.org/1230133005) added a kAttributeLayoutBlocking to requests, which is fantastic. It'd be phenomenally valuable if that attribute's value is exposed into a trace event. Can the value to carried over to resource_loader or framefetchcontext and added to one of the events there?
,
Apr 7 2016
Caseq and I just looked at the code some more. If I'm reading this right, browser takes the priority from Blink. Blink may choose to later reprioritize it (which AFAICT only happens to images). Once the HTML has a body, then kAttributeLayoutBlocking isn't set any longer, so even though subsequent requests are technically layoutBlocking, they're not blocking the FIRST layout. So, it seems like this attribute isn't exactly the "layout blocking" definition we need for Critical Path analysis. From my read, Blink's initial (and reprioritized) network priorities are more valuable to us than these signals at the browser layer. Given, that I think we'll doubledown on using the priorities, that is until a similar attribute is attached in Blink for layout-blocking (post HTML). (Closing this for now but feel free to comment if anyone has questions) |
||
►
Sign in to add a comment |
||
Comment 1 by paulir...@chromium.org
, Apr 7 2016