performance: forced-reflow while tns init

[staabm]

Issue description:
when initializing the slider one can see some "forced-reflow errors" in the chrome dev-tools which indicate some clientside performance problems with tiny-slider.

Demo link/slider setting:
please find my exported chrome developer tool profile tiny-slider_chrome-profile.zip

see https://developers.google.com/web/fundamentals/performance/rendering/avoid-large-complex-layouts-and-layout-thrashing#avoid-forced-synchronous-layouts for further background.

Tiny-slider version: 2.6.0 Browser name && version: Chrome 67.0.3387.0 OS name && version: Windows10 x64

[staabm]

our init js code looks like

    function initSlider5356() {
        var sliderRoot = document.querySelector('#cmsmoduleid5356');

        var sliderContainer = sliderRoot.querySelector('.slider');

        if(sliderContainer)
        {
            var slider = tns({
                container: sliderContainer,
                controlsText: ['', ''],
                speed: 1000
            });

            sliderContainer.classList.remove('initialstate');
        }

        var carSearchSlider = sliderRoot.querySelector('.car_search_slider');

        if(carSearchSlider) {
            var controls = carSearchSlider.nextElementSibling;
            var slider = tns({
                container: carSearchSlider,
                controlsContainer: controls,
                controlsText: ['', ''],
                loop: false
            });
        }
    }

[staabm]

2 takeaways:

• it looks like most of those results of getViewportWidth(...) are required for fixed-width cases only. would it make sense to only trigger the calls when fixed-width is configured for the current slider instance?

• would it make sense to use getBoundingClientRect() instead of traversing the tree upwards (see getViewportWidth() implementation)

• would it make sense to use requestAnimationFrame() so we dont trigger reflows at layout+paint rendering phases?

[ganlanyuan]

Hey, thanks for the report.

• getViewportWidth() is required for other case too, but I will reduce the function calls if it's not fixedWidth. Done in this commit.
• I can't just use getBoundingClientRect() in case of the container is display: none with which I just get 0. Check out a related issue #148
• For the use of requestAnimationFrame(), I will consider it.

Thanks

[staabm]

I can confirm a improvement regarding reflows... they are less expensive now.. ? getViewportWidth() is still showing up in the chrome dev panel, though:

chromes measures the following perf hit: el.clientWidth is triggering reflows.

[staabm]

another idea on how this could be improved: how about doing the calcuation/init stuff not at construct time but use a IntersectionObserver and do it only for those which are in the currently rendered viewport (or very near to it)?

[ganlanyuan]

el.clientWidth will cause browser recalculations but it has to be like this. Do we have a better solution? For lazy initiating sliders, it's better to do on user (your) side. If I'm going to do this with IntersectionObserver, I have to add a polyfill as well. It will be too much for the slider.

[staabm]

having browser recalculations from el.clientWidth is not the problem, but doing them outside of a requestAnimationFrame is. when doing this kind of things inside a requestAnimationFrame will make the live for the browser easier.

Let the lib user decide on IntersectionObserver is the way to go, you are right. shouldn't be done by the lib itself. good point.

after using the current version from master on my app I can see other code which also is marked as a perf problem:

[ganlanyuan]

For addCSSRule(), I decided to use it because I don't want to calculate the slide sizes and change their styles every time when clicking the navs or controls. I think it's much better just use CSS to achieve it for one time rather than do it with JavaScript over and over again.

[staabm]

If I understand it correctly the addCSSRule thing would not be a problem when we get it in the correct rendering phase -> requestAnimationFrame.

I would not add another dependency, but a experiment using fastdom could bring in some light as it will separate read/write dom operation and executes them at the "correct time".

https://github.com/wilsonpage/fastdom

[ganlanyuan]

Thanks for the info, will definitely check this recently.

[paulvonber]

@ganlanyuan Is there any news here? as I still got reflow problems with latest version.

[ganlanyuan]

@entwicklerRepo I'm still working on some other small issues. I will check this after those are done.

[staabm]

@ganlanyuan any news?

[lindseybradford]

Just checking in to see if there's any movement on this.