Performant CSS3 animation (Simple animation still not performant in Chrome Developer Tools)

Question

I am struggling with finding a way to make CSS page transition perform well in google chrome.

In Chrome developer tools on the timeline I noticed some red markers and they all say the same thing: Long frame times are an indication of jank and poor rendering performance. Read more at the Web Fundamentals guide on Rendering Performance.

On the app that I was working on that seemed legit and I tried to investigate, but could not find the source.

I've make a simpler demo and I still get the red marker: http://codepen.io/anything/full/qOOpza/

.page {
  position:absolute;
  top:0;
  left:0;
  width:100%;
  height:100%;
  background:#ccc;
  &--1 {
    background:green;
  }
  &--2 {
    background: yellow;
  }
  &.moveToRight {
        animation: moveToRight ease .5s;
        animation-fill-mode: forwards;
    }

    &.moveToLeft {
        animation: moveToLeft ease .5s;
        animation-fill-mode: forwards;
    }
}


@keyframes moveToRight {
    from { }
    to { transform: translateX(100%); }
}

@keyframes moveToLeft {
    from { }
    to { transform: translateX(0); }
}

Answer 1

I have been playing around with ytour demo, and I found 2 issues:

First, changing from translate to translate3d improves (at least in my system) a little bit the performance. So, writing this

@keyframes moveToRight {
    from {     transform: translate3d(0%, 0px, 0px);  }
    to {     transform: translate3d(100%, 0px, 0px);  }
}

is better. (This has been told several times before, but it is always good to check).

Also, a new property should help somewhat . setting

will-change: transform;

should prepare the browser for a future change in this property. But I haven't been able to see any difference.

Second, there seems to be a problem in the way Chrome gathers statistics. You have "Screenshots" enabled. And this seems to be the main cause of the delays, the time that Chrome needs to render and store the screenshots.

By definition, the time needed by a performance tool to do its work shouldn't be computed in the analysis. But this doesn't seem to be the case here... I would say this is a bug.

At least in my case, changing both issues makes the red markers almost disappear

And, in the remaining marked frames, there doesn't seem to be any performance issue. Notice in the screenshot that the frame duration is 25.57 ms long, but the CPU time is 1.239 ms .