Forced reflow while executing javascript took 57ms

Saved searches

Use saved searches to filter your results more quickly

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Violation] Forced reflow while executing JavaScript took 42ms #335

[Violation] Forced reflow while executing JavaScript took 42ms #335

Comments

;(function ($)  var options = >; window.sr = ScrollReveal(options); sr.reveal('.sr-item',  viewFactor: 0.6, duration: 500 >); sr.reveal('.sr-item--seq',  viewFactor: 0.6, duration: 500 >, 50); >)(jQuery);

Hello. Today I’ve noticed a warning in the console on my site that I use scrollReveal on:

[Violation] Forced reflow while executing JavaScript took 42ms 

So I took timeline snapshot and saw this.

So the question is there any possible way I can improve perfomance? Thank you

The text was updated successfully, but these errors were encountered:

Источник

Saved searches

Use saved searches to filter your results more quickly

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Violation] Forced reflow while executing JavaScript took ms #1634

[Violation] Forced reflow while executing JavaScript took ms #1634

Comments

Some elements like (Dialog, Dropdown menu, Select, Popover, . ) cause a Forced reflow and this can lower the performance of the component and the entire page.

The text was updated successfully, but these errors were encountered:

I am having a similar issue, in my case with Dialog. Clicking the Dialog trigger takes up to 1 second, depending on the size of the page. The larger the page the bigger the lag. E.g. this page seems to have no delay, while this page suffers quite a bit. The issue seems a bit more severe on Firefox compared to Chrome (at least on my Intel MacBook Air), but it is very noticeable nonetheless. The following recording was taken on this page: https://dev.gesetzefinden.at/bundesrecht/bundesgesetze/abgb

Here’s a video showing the issue in action:

However, the issue only persists when modal is set to true , which leads me to believe that the issue is caused by the «aria-hidden» package on this line, as that is the only noticeable difference I could find between modal and non-modal implementations (but that’s just a guess):

Same here with select component

However, the issue only persists when modal is set to true, which leads me to believe that the issue is caused by the «aria-hidden» package on this line, as that is the only noticeable difference I could find between modal and non-modal implementations (but that’s just a guess):

It’s more likely to be an issue with re-layout because of react-remove-scroll which restyles the body.

I am not sure there is much to be done about this here, you could maybe experiment with CSS containment in your specific case to lower down the amount of reflow happening. Unfortunately as @andy-hook pointed out, these types of issues are rather specific to use-cases/complexity of specific pages.

It’s more likely to be an issue with re-layout because of react-remove-scroll which restyles the body.

You’re right, that seems to be a big part of the problem, but I think it’s not the only bottleneck. We have tried a workaround using modal= and handling body-scroll-locking manually. This approach still has some lag, but it is less severe. It’s consistently slower without the workaround (around 15-30%). Compare (opened/closed the dialog trigger 6 times each):

With modal= and manually setting «overflow: hidden» on the body (measured on this page):

I’ve done some quick profiling: the style re-calculation stayed roughly the same (which is expected), but the click handler is much faster on the non-modal version:

As you can see the click-handler in the took much longer. The messages in the console also changes from «click handler took » to «message handler too «. But maybe I’m misreading something

I’ll try adding more containment and maybe replicate with other libraries, and will report back 👍

Have you tried with non-modal and not implementing any scroll locking?

and handling body-scroll-locking manually

I’m also curious whether the upcoming native scrollbar-gutter would show a big improvement on these large pages.

Have you tried with non-modal and not implementing any scroll locking?

Non-modal without scroll locking is butter smooth (see below).

I’m also curious whether the upcoming native scrollbar-gutter would show a big improvement on these large pages.

I didn’t know about that property, thank you! I played around with scrollbar-gutter as well as body locking and have some interesting findings:

TL;DR The problem is not overflow: hidden , but rather touch-action: none / pointer-events: none and CSS custom properties set on the body

First, my scroll locking implementation was setting the following properties on the element: overflow: hidden , touch-action: none and a custom CSS variable —scrollbar-offset that is used to prevent the body or navbar from jumping when overflow: hidden is applied.

Just setting overflow: hidden is actually very fast. With Chrome there’s around 50-100ms lag caused by text-reflow at some widths. scrollbar-gutter: stable helps with preventing the layout shifts, but is not significantly faster compared to manually preventing the layout shift with margin-right: 15px . Also, scrollbar-gutter doesn’t seems to prevent layout shifts for elements with position: fixed like navbars or the modal itself, so I still need to work around that manually.

If I add either —scrollbar-offset CSS var or touch-action: none (or both) to the element I start to see a 200-350ms lag with a message appearing in the console telling me about a forced reflow ( pointer-events: none had the same effect). CSS vars are inheritable so that might simply be bad performance (see bug 1056209). Why touch-action is so slow I don’t know, but maybe it’s not needed anymore in modern browsers anyways?

I will try implementing the following and then report back:

• Use scrollbar-gutter if available and fall back to setting margin-right: px to prevent layout shift on the body
• Remove touch-action: none
• Remove —scrollbar-offset and replace with a JS solution where components that need it can subscribe to it (e.g. via Zustand)

Источник