They also point out that substantial performance gains are given by using 'will-change,' as in the following.

  .app-menu {
	-webkit-transform: translateX(-100%);
			transform: translateX(-100%);
	transition: transform 300ms linear;
	will-change: transform;

}

And I'd point out that the authors are specifically stating that animating transform+opacity (via a 'transition') are more efficient than things like left, top, bottom, etc.—because those properties affect the layout stage, which is earlier than the composite stage (where the transform+opacity properties operate), and subsequent stages have to be recalculated.

They also discuss different ways of structuring DOM trees to create the same animation which have performance trade-offs.

Yep, the will-change was something new to me.

This appears to be browser specific.

I copied his code-pen and used his first example in Safari (just using the `left` css property) and it was still 60 FPS in Safari (per debugging tools). I wonder how much variance there is between browsers on this. (I'm on a Mac 10.12.5 using Safari 10.1.1 (12603.2.4))

There are a lot of jsperf tests like this one https://jsperf.com/translate3d-vs-xy/4

This isn't pure css as it's using JS to set the property, but it should be a good indicator.

I'm not an expert in this area, but doesn't setting these properties only take effect in the next layout/paint cycle?

I think you need to call getComputedStyle (https://developer.mozilla.org/en-US/docs/Web/API/Window/getC...) to resolve the new style update outside of the layout/paint cycle.

But I'm not really sure to be honest

All CSS advice around "this causes the creation of a compositing layer" is browser-specific. Chrome and Safari happen to have a particular compositing model but AFAIK there's nothing in the HTML spec that actually requires it.