Slick.js and Hero Banner: The Hidden WordPress Speed Killers

The Bottleneck Nobody Expects

When Images Are Not the Real Problem

The instinct when a WordPress site has a poor PageSpeed score is to focus on images — compress them, convert them to WebP, lazy load them. On most sites, this instinct is correct. But on sites using JavaScript-powered carousels or sliders for their hero banner, image optimization alone will not be enough. The carousel script itself becomes the primary bottleneck, and no amount of image compression will resolve it.

Slick.js is one of the most widely used carousel libraries in WordPress themes and plugins. It is lightweight, responsive, and easy to implement — which is why it is so common. It is also one of the most frequent causes of poor LCP scores on image-heavy sites. The issue is not the library itself but how it loads and initializes images.

How Slick.js Delays LCP

Slick.js initializes by loading all slide images before displaying any of them. On a carousel with five large banner images, the browser cannot render the first slide until all five images have been downloaded. This significantly delays LCP, because the largest visible element — the banner image — cannot be painted until the JavaScript has finished loading all slides.

This behavior is compounded when the Slick.js script itself is render-blocking — meaning the browser pauses HTML parsing while the script downloads and executes. On a mobile connection, this can add two to four seconds to LCP on its own, before accounting for image file sizes.

Diagnosing the Issue

Reading the PageSpeed Insights Waterfall

In the PageSpeed Insights report, open the Opportunities and Diagnostics sections and look for references to render-blocking resources, unused JavaScript, or specific script filenames. If slick.min.js or a carousel-related script appears in the render-blocking resources list, that is confirmation that the carousel is contributing to LCP delay.

The Filmstrip view in GTmetrix is also useful for this diagnosis. It shows a frame-by-frame rendering timeline of the page load. If the page remains blank or shows a layout without the hero image for the first two or three seconds, the carousel initialization is likely the cause.

Solutions

Defer the Slick.js Script

The simplest intervention is to defer the Slick.js script so that it does not block HTML parsing. In LiteSpeed Cache’s Page Optimization settings, the JS Defer option defers all scripts that are not marked as critical. This allows the browser to parse and render the HTML before executing JavaScript, which improves LCP even if the carousel still loads all images on initialization.

Test this change carefully. Some carousels require their initialization script to run before the page is fully rendered in order to calculate dimensions and layout correctly. Deferring in these cases can cause a flash of unstyled content or a briefly broken layout before the carousel initializes.

Load Only the First Slide Initially

A more effective solution is to restructure the carousel so that only the first slide image is present in the HTML on initial load, with remaining slides loaded dynamically after the page is interactive. This requires modifying the theme or plugin that outputs the carousel markup, which is a developer-level change. The result is that LCP is determined by a single optimized image rather than by the time required to load all carousel images.

Replace the Carousel with a Static Hero

For clients who are open to design changes, replacing the JavaScript carousel with a static hero image is the most effective performance intervention available. A static image with no carousel script eliminates the render-blocking issue entirely, reduces JavaScript payload, and significantly simplifies the LCP calculation. Carousel engagement rates are also generally low — most visitors do not interact with auto-advancing sliders, making the performance cost difficult to justify.

Summary

Slick.js and similar carousel scripts are a hidden performance cost on many WordPress sites. They are easy to miss in a standard optimization audit because the issue is not image size but script loading behavior. Identifying the carousel as an LCP bottleneck, deferring its script, and where possible restructuring how it loads images are the most effective interventions available without a full design change.

The next article covers lazy loading — a technique that is widely recommended for performance but that causes specific problems when configured incorrectly, including content that requires scrolling to appear.