Audit: Attribute mainthread costs by framework

[evenstensberg]

Don't know if this is possible, close if irrelevant or if this is implemented in some way.

Summary

I think it would be convenient to include how much of the framework code is included in the FMP or TTI. This way, authors have more of an indication of what code they need to strip in order to gain a good audit on TTI or FMP. Tools that are reliant on lighthouse could also benefit from this, as you could with, for instance webpack, make sure to split your bundles into vendor chunks. Don't really know how to approach this problem though.

https://youtu.be/aCMbSyngXB4?t=2m55s

CC-ing in @addyosmani for more thoughts.

[tdresser]

I suspect we can do something like this.

We have approximate code coverage data - we just need to take a snapshot at FMP or TTI.

[evenstensberg]

I think the hard part would be to split your code from the framework associated code, as this sometimes intersects. I may be wrong though

[patrickhulce]

This would be great! I also fear this falls into the problem of the more sophisticated the user (bundling assets where coverage data is difficult to disentangle, etc) the less likely we'll be able to accurately report this information, which is unfortunate since I suspect they're also the most likely to take action on it.

[tdresser]

Is splitting out framework logic necessary for this?

I would have thought just indicating what code had executed at the time of FMP/TTI would be pretty useful.

[brendankenny]

let's close and defer to a few other issues like

• bundle/source-map analysis: JS analysis #9097
• third-party wrapping attribution: Performance Audit attribution from third-party wrapping #7005
• third-party identification improvements: Use third-party-web's definition for 3P entities #7474
  etc