&gt;  I think the browser specs are broken such there will always be pathological cases, and always cases where &#x27;you&#x27;re on the performance rails&#x27;. End users don&#x27;t care.<p>In the case of GPU acceleration, the specs are not broken. There is no fundamental reason why animations on arbitrary properties cannot be GPU accelerated and some can be. Ask anyone who&#x27;s worked with Scaleform whether rapidly changing vector graphics (which is all these animations are) has to be slow on mobile.<p>For style recalculation, maybe, maybe not; it&#x27;s not clear to me that browsers are worse than native app frameworks here, except that we&#x27;re missing Typed CSSOM, which is important spec work.<p>&gt; This is no different on any other platform. If you program games directly to OpenGL, for example, you run into all kinds of different bottlenecks, both CPU and GPU. Depending on the pipeline of the various GPUS, and what kinds of hazards they have, there&#x27;s stuff you have to avoid, or branching paths you have to handle to get good performance.<p>And game engine authors are fed up with it, which has led to Metal, DX12, and Vulkan. It&#x27;s not a good way to treat developers; we should try to give them APIs in which, as much as possible, everything is fast. I think the Web APIs can be that, if implemented optimally.<p>&gt; I think it is asking too much of browsers to give them such a huge surface area spec as HTML and CSS, and then ask for them to optimize everything so there&#x27;s no slow paths.<p>I&#x27;m not saying that we have to pretend everything in HTML and CSS can be made <i>equally</i> fast. My point is that, in many areas, browsers have done a bad job of even trying to optimize broadly. Take animations, for example: the only thing browsers optimize is two properties out of hundreds, transform and opacity. This is exceptionally problematic, given that there&#x27;s no technical reason why this has to be the case. I just gave a talk about this a few days ago :)