layerslider loading after all the homepage content causing blank screen and layout shift after loading. The Layerslider is located in the herop section and is supposed to load first. Kindly assist.
Unfortunately this behavior is quite common with JavaScript-based sliders (including LayerSlider): the slider can only initialize after the page’s HTML is available (i.e., once the document has loaded enough for the scripts to find the slider markup and build the layers). Images may still continue loading afterward, but the initial JS render can’t reliably happen “before” the document/content exists, so you can see a brief blank area and a layout shift.
That said, you can usually eliminate the blank screen + reduce (or fully remove) the layout shift with a few practical tweaks:
Disable lazy-loading / delayed rendering for the hero slider
If your theme, page builder, or an optimization plugin is lazy-loading the hero section (or delaying JS execution), the slider will appear late. Try excluding LayerSlider (and jQuery, if applicable) from:
“Delay JavaScript execution”
“Defer JS”
“Async JS”
Script combination/minification (temporarily, to test)
Check optimization/caching plugins first (very common cause)
Plugins like WP Rocket / LiteSpeed Cache / Autoptimize / Perfmatters (and some hosts’ server-side optimizers) can delay the slider scripts, which makes the hero render only after everything else.
Use a lightweight placeholder/fallback background in the hero
Set a static background image/color on the hero container (behind the slider) so even if initialization takes a moment, visitors won’t see a white/blank flash.
Reduce the slider’s initial load cost
Big background videos, too many layers, large images, or external fonts in the hero can increase the time until the first meaningful render. Optimizing the hero assets helps a lot.
I have implemented the changes that enaled the layerslider javascripts (utils & jquery), css and Slide 1 hero image to be given high priority. From Chrome tool, I can see they are downloaded in under a second. However, they can't be processed on time to achieve recommended LCP and CLS scores for mobile layout. The main issue that I have discovered is that at the initial page load, the browser reserves a larger height typically about 3 times of what the actual height the Layerslider requires in mobile layout. Whether you use a plain background or coloured background for the layerslider, the initial height remains large. Once the layerslider js & css executes, the height collapses and the content moves up. This gives very bad LCP and CLS scores especially on mobile layout. The desktop layout is generally ok because the reserved height almost matches the final slider height. So I have used a light hero webp image of 16kB as the slider container background which is immediately displayed during page load. This has helped to attain 90%+ pagespeed score for Desktop layout. But on mobile, the hero image occupies the initial height and is cropped out and distorted. Once the layerslider script executes, it is properly displayed. Though there has been an improvement after adding slider container hero bg, I still get poor scores because of CLS which also influences how pagespeed calculates LCP. I think there is a issue with your code where the Layerslider uses desktop height as the initial height for the Mobile layout. Kindly check and revert. I would be glad to have an updated Layerslider 8 which I can keep for the homepage.
Thanks for the detailed explanation — that’s very helpful. To understand why the browser reserves ~3× the height on mobile before LayerSlider initializes, could you please confirm a few exact settings?
What Slider Layout are you using?
What are your “Initial size” values in LayerSlider?
Do you have any responsive/mobile-specific settings enabled?
Once we have the exact layout + initial size setup, we can tell whether this is coming from the slider’s configuration (most commonly an Initial size / responsive breakpoint mismatch), or whether something on the theme side is forcing an incorrect height before initialization.
layerslider loading after all the homepage content causing blank screen and layout shift after loading. The Layerslider is located in the herop section and is supposed to load first. Kindly assist.
Hi Lawrence,
Unfortunately this behavior is quite common with JavaScript-based sliders (including LayerSlider): the slider can only initialize after the page’s HTML is available (i.e., once the document has loaded enough for the scripts to find the slider markup and build the layers). Images may still continue loading afterward, but the initial JS render can’t reliably happen “before” the document/content exists, so you can see a brief blank area and a layout shift.
That said, you can usually eliminate the blank screen + reduce (or fully remove) the layout shift with a few practical tweaks:
Disable lazy-loading / delayed rendering for the hero slider
If your theme, page builder, or an optimization plugin is lazy-loading the hero section (or delaying JS execution), the slider will appear late. Try excluding LayerSlider (and jQuery, if applicable) from:
“Delay JavaScript execution”
“Defer JS”
“Async JS”
Script combination/minification (temporarily, to test)
Check optimization/caching plugins first (very common cause)
Plugins like WP Rocket / LiteSpeed Cache / Autoptimize / Perfmatters (and some hosts’ server-side optimizers) can delay the slider scripts, which makes the hero render only after everything else.
Use a lightweight placeholder/fallback background in the hero
Set a static background image/color on the hero container (behind the slider) so even if initialization takes a moment, visitors won’t see a white/blank flash.
Reduce the slider’s initial load cost
Big background videos, too many layers, large images, or external fonts in the hero can increase the time until the first meaningful render. Optimizing the hero assets helps a lot.
Best Regards,
George | Kreatura Dev Team
I have implemented the changes that enaled the layerslider javascripts (utils & jquery), css and Slide 1 hero image to be given high priority. From Chrome tool, I can see they are downloaded in under a second. However, they can't be processed on time to achieve recommended LCP and CLS scores for mobile layout. The main issue that I have discovered is that at the initial page load, the browser reserves a larger height typically about 3 times of what the actual height the Layerslider requires in mobile layout. Whether you use a plain background or coloured background for the layerslider, the initial height remains large. Once the layerslider js & css executes, the height collapses and the content moves up. This gives very bad LCP and CLS scores especially on mobile layout. The desktop layout is generally ok because the reserved height almost matches the final slider height. So I have used a light hero webp image of 16kB as the slider container background which is immediately displayed during page load. This has helped to attain 90%+ pagespeed score for Desktop layout. But on mobile, the hero image occupies the initial height and is cropped out and distorted. Once the layerslider script executes, it is properly displayed. Though there has been an improvement after adding slider container hero bg, I still get poor scores because of CLS which also influences how pagespeed calculates LCP. I think there is a issue with your code where the Layerslider uses desktop height as the initial height for the Mobile layout. Kindly check and revert. I would be glad to have an updated Layerslider 8 which I can keep for the homepage.
Hi Lawrence,
Thanks for the detailed explanation — that’s very helpful. To understand why the browser reserves ~3× the height on mobile before LayerSlider initializes, could you please confirm a few exact settings?
What Slider Layout are you using?
What are your “Initial size” values in LayerSlider?
Do you have any responsive/mobile-specific settings enabled?
Once we have the exact layout + initial size setup, we can tell whether this is coming from the slider’s configuration (most commonly an Initial size / responsive breakpoint mismatch), or whether something on the theme side is forcing an incorrect height before initialization.
Best Regards,
George | Kreatura Dev Team