Q:

Angular Animation Performance State/Transition vs Query

I am currently working with angular animations.  Therefore I figured out two possible methods to attach animations to components.  In the following I am describing them as State/Transition-Animations and Query-Animations. 
In this question I mainly want to know if there is a performance difference in going for one or the other way!? 

1.  State/Transition-Animations
.html
<div [@animation_foo]/>

.ts
trigger('animation_foo', [
    state('true', style({...}),
    state('false', style({...})       
    transition('true => false', animate(...)
]

2.  Query-Animations
.html
<div [@animation_foo]>
    <div class="bar"/>
</div>

.ts
trigger('animation_foo', [
    query('.bar', style({...}), animate('10ms', style({...}))
]

Further thoughts:

My main concern with point 2.  Query is that:

If you do not have one query but multiple, which are combined via group(...) and the css selector is going to find elements on a deeper level ('.foo > :nth-child(n+3) .bar') you have to iterate over a very big part of the DOM-Tree. 
The stylings and animation applied to the elements happens after finding the element and before the animation - every time - because I expect, that it cannot be pre-compiled by the compiler? 

Environment/Target platform: I know it's might not related to a casual Web-Application, but I try to think in big enterprise applications with multiple router, nested components and lots of ngIf's ngFors, so that I personally can imagine that querying all that could be some effort. 

Browser: I know that browser differently behave differently.  Personally I am interested only in Chrome for the moment - But for the sake of community a general answer would be awesome. 

If you have any further information that are important to note, it would be nice to share (bugs, ...)

A:

Angular uses the web animations api, so it's not changing style properties through JavaScript and is therefore quite performant.  You can check the performance of different animation frameworks (javascript-based) vs CSS with the HTML 5 Animation Speed Test.  
The performance in different browsers is therefore dependent on the browser compatibility of the web animations api (unfortunately the section is not being maintained yet).  But, according to the comment here, it is not fully supported yet across common browsers and is being polyfilled for Edge/Safari.