@gmajoulet From our private chat as well.

I fundamentally disagree with the approach being "too complicated", since the author includes the pre-animation CSS intentionally in any case. It's also exactly the way you have to do it on any document, it doesn't depend on our constraints nor the AMP format.

What you're asking is not feasible at this level. Anything else would make the animations engine render-blocking, which is against our performance concerns.

If you'd like to solely update the implementation for <amp-story-animation> then by all means, but you're going to get a terrible user experience unless you make it render-blocking. If you make it render-blocking, the whole document will take longer to paint.

Two things:

1. A document that takes longer to paint is better than a document that does not paint
2. We're a team of solid and experienced frontend engineers, we will together find a solution that works for our users and delivers great UX and performance

Going to merge this PR as is and schedule some time for a followup conversation to discuss the points brought up.

Thank you all for working to make this happen and looking forward to the next steps.

Matias is working on a proper fix here: #34466

We know the ecosystem well enough to know that adding a few lines in the documentation and expect publishers to write complex code to solve something they don't even know of won't work. I don't think we need to meet to discuss this further.