React-reveal only working when scroll is stopped- chrome

Question

I am running into a weird issue with chrome when implementing react-reveal. What is happening if the animation is not running when you scroll down the page, until you stop and then the animation runs as expected. Has anybody had any experience with this issue? Cheers in advance

Implementation

So i simply made a fading div component, something like

class FadingDiv extends Component {
...
  render() {
    return (
        <Fade>
           <div className={this.props.className}>
             {children}
           </div>
        </Fade>
    )
  }
}

And then simply switching out the div tags with FadingDiv where i want to implement the effect. This works great with safari and firefox, but (suprisingly) chrome is giving me issues. Any help would be massively appreciated, i feel a bounty incoming.

Polard

any reproducible snippet?.. – Caphaitien

Cant exactly post the specific code no. It seems to be a problem with chrome de-prioritising scroll events ( from what i've researched ), and i feel that a lottie animation within my page has caused this. – Polard

I looked over the issue it looks like you posted (github.com/rnosov/react-reveal/issues/16) and the related loading optimization issue they referenced (github.com/aFarkas/lazysizes/issues/139). Did you try anything in the spirit of this second thread as a hack/fix? – Ensample

It looks like most of the material I can find about Chrome on this is dated (optimizing timing of paints). Have you tried using Chrome's dev tools to track when paints are happening and find the bottleneck? (developers.google.com/web/fundamentals/performance/rendering/…) – Ensample

It looks like you can also use the CSS will-change property to sometimes override performance defaults on when things are painted vs not (developer.mozilla.org/en-US/docs/Web/CSS/will-change) – Ensample

Lmk if any of this helps to diagnose the problem. – Ensample

@JessB thanks for your help, it does indeed seem to be chrome de-prioritising scroll events because the animation i have going on. Is there anything i can do from my end to better this? At the moment ive simply disabled the scroll animation when viewed in chrome. – Polard

@JessB the bottleneck seems to occur when the animation is initially loading, if i let that go for a while, all animations when scrolling work well. Also a slow connection disables them – Polard

Makes sense, did you see if will-change on the animation or any of the other hacks could successfully alter the priority enough to get a decent initial load? What's the goal for how the page loads? You might be able to restructure the order of the page loading or your event triggering scheme to get the behavior you want. – Ensample

@JessB i did try, however the team and i do believe it is because of the stress our other animations are putting on the browser. Thanks so much for the help, would be willing to give you the bounty if you could post an answer – Polard

Makes sense, managing the load on the browser is tricky. I hope you can get that working the way you're wanting it. Great, yeah I can put the resources I gathered in an answer, in case someone else has a similar question. – Ensample

Answer 1

So looking over the issue posted in the react-reveal package, and the related loading optimization issue they referenced, it looks likely that it's an issue with how Chrome prioritizes the loading and/or rendering of elements.

As mentioned in the second thread, there are a variety of hack-type fixes that might be able to alter Chrome's prioritization of events to favor the animation, depending on how the page currently is built. For instance, you might be able to explicitly force events on scroll or scroll end to override defaults. Or you might be able to add attributes either to the element or its sibling elements that force them to identify at a higher or lower priority.

It looks like a lot of the material out there on exactly how Chrome prioritizes both loads and paints is dated, but here is an updated resource on loading priority and another one on rendering that might be helpful.

If there is another element putting pressure on the browser's rendering/painting and deprioritizing the one under discussion, you could diagnose where the bottleneck is using Chrome's dev tools to track the timing of paints. (More about that here and here and here.) It looks like the diagnostics available are pretty great: they can get pretty detailed and include tracking priority.

Another thing you could try using is the CSS will-change property. It's another hack-type fix, but it looks like it can also be used to override performance defaults to favor an element with an upcoming animation.

Depending on the goal for how the page loads and what the other elements are, hopefully some of this helps to diagnose the bottleneck, and from there alter the prioritization enough to get the behavior you want.

Ensample

Answer 2

Okay, I think I've managed to partially reproduce this issue on when I was designing mobile version of React Reveal frontpage (a lot of image animations). Someone else has also reported similar issue. I've dived deep into how Chrome prioritizing event handlers and managed to come up with a several tweaks to react-reveal event handler that seem to help a lot with getting much higher priority and better performance under heavy load. You can try it by installing a dedicating beta with everything thrown in:

npm i [email protected]

See if it solves your issue. Please, do report results as I'm having with reproducing it on a desktop. I'll also push slightly toned down fix in 1.1.9.

Tegantegmen

Hi! Just been playing around with it, and your newest release seems to be fixing the issues i was having. Still playing around with mobile, but the scroll listener seems to be functioning much better :) – Polard

I've managed to push the reveal detection code completely off the main thread in 1.2.0 release. Hopefully, that would resolve any performance issues in Chrome once and for all. – Tegantegmen