Hero image stays blank until the whole page has loaded

01Why the banner waits for the whole page

The usual advice, on threads like this one (Aug 2023), is to stop lazy-loading the first slide, and that matters (web.dev, lazy-loaded LCP images). On both stores we fixed, the first image already loaded eagerly. It downloaded, then waited for a script.

1. 01

   The slider waits for load

   Slider set-up code often says “start now if the library is ready, otherwise on window load”. If that code sits inline in the section and the library is loaded with defer, the inline code always runs first, finds no library, and waits for load. MDN: the load event fires “when the whole page has loaded, including all dependent resources such as stylesheets, scripts (including async, deferred, and module scripts), iframes, and images, except those that are loaded lazily” (MDN, load event). On a store with several apps, that is close to the last thing to happen.

2. 02

   The first slide is hidden until the slider starts

   Themes often keep the slideshow at opacity: 0 until it is set up, to avoid a jump. Put that together with the above and the banner stays blank for the whole page load.

3. 03

   A lazy-image script holds the first image back

   Some themes hide each image while their script marks it as loading, then fade it in once it has loaded. On the first slide, that ties the banner to the script being ready, the image’s load event, and a fade.

02Find what the banner is waiting for

For store owners: is your banner waiting for a script?

1. 1

   Load the homepage on a slow connection

   In Chrome on a computer, open the developer tools (View > Developer > Developer Tools on a Mac, ⋮ > More tools > Developer tools on Windows), choose Fast 4G in the Network tab, and reload. Watch whether the banner appears with the first things on the page, or near the end.

2. 2

   Switch JavaScript off and reload

   With the developer tools open, press Cmd+Shift+P (Ctrl+Shift+P on Windows), type Disable JavaScript, choose it and reload. If the banner image shows straight away now, the theme’s script is what holds it back. Send your developer what you saw, and switch JavaScript back on the same way.

For developers: paint first, start the slider after

This is the shape of what we shipped, generalised:

{%- style -%}
  /* Before the slider starts: show the first slide, hide the rest. */
  #Slideshow-{{ section.id }} .swiper:not(.swiper-initialized) .swiper-slide { width: 100%; flex-shrink: 0; }
  #Slideshow-{{ section.id }} .swiper:not(.swiper-initialized) .swiper-slide + .swiper-slide { display: none; }
{%- endstyle -%}

<div id="Slideshow-{{ section.id }}">
  <div class="swiper">
    <div class="swiper-wrapper">
      {%- for block in section.blocks -%}
        {%- liquid
          assign loading = 'lazy'
          assign priority = 'auto'
          if forloop.first and section.index == 1
            assign loading = 'eager'
            assign priority = 'high'
          endif
        -%}
        {%- if block.settings.image != blank -%}
          <div class="swiper-slide">
            {{ block.settings.image | image_url: width: 2000 | image_tag:
              loading: loading,
              fetchpriority: priority,
              sizes: '100vw',
              widths: '750, 1100, 1500, 2000, 2400' }}
          </div>
        {%- endif -%}
      {%- endfor -%}
    </div>
  </div>
</div>

function startSlider() {
  // new Swiper(...) or your slider's set-up
}

// Deferred scripts run before DOMContentLoaded, so the library is ready by then.
if (typeof Swiper !== 'undefined') {
  startSlider();
} else {
  document.addEventListener('DOMContentLoaded', startSlider);
}

• MDN: DOMContentLoaded fires “when the HTML document has been completely parsed, and all deferred scripts ... have downloaded and executed” (MDN, DOMContentLoaded). It “doesn’t wait for ... async scripts”, so load the slider library with defer, not async.
• Only the first slide of the first section is eager and high priority (section.index is 1-based, and is nil in the theme editor, in static sections and through the Section Rendering API, so there the check falls back to lazy: measure on the preview link, not in the editor). The other slides stay lazy.
• fetchpriority="high" on the main image makes it load sooner (web.dev, Fetch Priority).
• For the first slide, image_tag’s preload: true also starts the download before the browser reaches the image: Shopify sends it as a Link header with rel=preload, and the <img> itself doesn’t change (Shopify, image_tag). Set it on that one image only; Shopify says to use it “sparingly”.
• No fade and no loading class on the first slide. If the theme has a lazy-image script, leave the first image out of it.
• A desktop and a phone image: use one <picture> with a <source media> for the phone image, so each device downloads one. Two eager <img> tags with one hidden by CSS both download.
• Look for the same load fallback in other sections. Theme code is often copied from one section to the next.

03Check with JavaScript off, then on

1. 1

   JavaScript off

   The first slide shows, and the other slides don’t stack under it.

2. 2

   JavaScript on, Fast 4G

   The banner appears with the first content on the page, and the slider then starts without a jump.

3. 3

   Find the main element

   In the Performance panel, record a reload. The Largest Contentful Paint should be the first slide’s image, and come early.

4. 4

   Count the images

   In the Network tab, filter by Img on a phone-sized window and on a desktop one: one banner image each, not both.