Looks like this is because compositor animations only support keyframe easing and not animation easing.

Not sure why it only occurs when neutral keyframes are used though. Here's a test case that includes non-neutral Web Animations: https://jsfiddle.net/LL6k3w76/1/

The compositor supports animation easing, the problem is the default easing for keyframes is "ease" while that's not the case for Web Animations.
The out of sync animation actually has "ease" applied twice.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/99d5466b3824d1170c02088d7c38e2ca1e53c95b

commit 99d5466b3824d1170c02088d7c38e2ca1e53c95b
Author: alancutter <alancutter@chromium.org>
Date: Fri Apr 15 04:51:39 2016

Use "linear" as the default easing for neutral keyframes in element.animate()

By explicitly setting "linear" as the default keyframe easing when using
element.animate() we don't accidentally start compositor animations
using their default of "ease".

BUG= 601407 

Review URL: https://codereview.chromium.org/1866153003

Cr-Commit-Position: refs/heads/master@{#387537}

[add] https://crrev.com/99d5466b3824d1170c02088d7c38e2ca1e53c95b/third_party/WebKit/LayoutTests/animations/translate-neutral-keyframe-easing-expected.html
[add] https://crrev.com/99d5466b3824d1170c02088d7c38e2ca1e53c95b/third_party/WebKit/LayoutTests/animations/translate-neutral-keyframe-easing.html
[modify] https://crrev.com/99d5466b3824d1170c02088d7c38e2ca1e53c95b/third_party/WebKit/Source/core/animation/EffectInput.cpp