Right now any amount of time that main thread is blocked on compositor thread is counted into "Composite Layers" Category in timeline recordings.

This tells the developer that there is an issue with their compositing pipeline but does not help identify it. Off the top of my head I can think of a few major causes for a large "Composite Layers" cost:

1. Syncing trees is expensive: e.g., perhaps there are too many layers
2. Last frame pending tree is not activated so we are waiting on that e.g., perhaps raster tasks are taking a long time
3. Last frame active tree is not drawn yet and we are waiting on that e.g., GPU is busy doing work 

At the moment, I have to know the inner working of Blink CC to be able to make these attributions and then try to fix the issue. Perhaps devtools should help break this down specially that we already surface GPU, raster tasks but it is not clear how those costs can lead to a large "Composite Layers" cost causing a long frame.


For an example see this screenshot devtools recording of music.google.com which has large 10ms Composite Layer cost.
 

Deleted: google-music-devtools.png 112 KB

	google-music-devtools.png 112 KB View Download