slick is blocking the main thread possibly causing worse Core Web Vitals scores for LCP and FID

[Tiggerito]

I wrote an article on this, but think it would be worth baking a solution onto Cornerstone. It contains more details on the issue and solution:

I was doing a case study for a store related to getting them to pass their Core Web Vitals. In the process, I found that they sometimes had up to three slick sliders on a page, and they were blocking the main thread for a long time, causing a delay in rendering and stopping user interaction.

The relatively simple change splits the code up into multiple tasks, which lets other code, like the renderer, run in between them. I also built a way to delay the building of a slider (data-slick-delay) to further give time for more important code to run.

` // Let each carousel define its own delay const delay = $carousel.data("slickDelay") || 0;

    setTimeout(() => {
        $carousel.slick({
            accessibility: false,
            arrows: isMultipleSlides,
            customPaging,
            dots: isMultipleSlides,
        });
    }, delay);  `

    data-slick-delay="2000"
    data-slick='{
        "arrows": {{arrows}},
        "mobileFirst": true,
        "slidesToShow": 1,
        "slidesToScroll": 1,
        "autoplay": true,
        "autoplaySpeed": {{carousel.swap_frequency}},
        "lazyLoad": "anticipated",
        "accessibility": false
    }'>```

It would require some decision-making on how long each slier should be delayed. e.g. any below the fold can have a long delay.

The sliders also need to be checked to ensure the pre-slider look matches the initial post-slider look.

[emilian]

You could also try the approach of initializing the slick slider when the parent container is visible using IntersectionObserver.