- Published
- Byline
- GoHighLevel Partners Editorial
- Filed under
- GoHighLevel Automation
It has one reliable way of making things worse, and it is the one applied by default — deferring the image at the top.
Lazy loading funnel images: what it fixes and what it breaks
Lazy loading defers fetching an image until the visitor is close to seeing it. On a long funnel page carrying a dozen images, that is a genuine improvement: the visitor waits for the first screen rather than for the whole page, and the images further down arrive as they scroll.
It also has one reliable way of making things worse, and it is the one people apply by default — lazy loading the image at the top. That image is what the visitor is waiting for, and deferring it delays the moment the page appears to have loaded at all.
The rule that covers most cases
| Image position | Treatment | Why |
|---|---|---|
| The main image on the first screen | Load eagerly, and give it priority | It is what the page’s perceived load time is measured against |
| Anything else above the fold | Load eagerly | Deferring something already visible produces a visible pop-in |
| Images below the fold | Lazy load | Most visitors never reach some of them |
| Images inside a collapsed section | Lazy load | They may never be opened at all |
| Background images in later sections | Lazy load where the builder allows | Often the heaviest assets on the page |
The distinction is not “above or below the fold” in the abstract — it is whether the image is part of what the visitor sees while deciding the page has loaded. On a phone the fold is much higher up, and a hero image that sits comfortably in view on a desktop may be the only thing visible on a handset, which makes getting this wrong more costly there. The reordering in how a phone stacks your columns also moves which images are near the top, so the answer can differ between widths.
Reserve the space, always
The problem lazy loading creates is layout shift: the image is not there, the content below sits higher, and when the image arrives everything moves. A visitor who was reading, or about to tap something, is now doing neither.
Reserving the dimensions prevents it entirely, and it costs nothing but knowing the size. This is worth doing for every image whether lazy loaded or not, and it is one of the largest contributors to the measurements described in what a page speed score measures. The same class of problem appears with embedded content, which is part of why why an embedded frame clips happens.
Where lazy loading actually breaks things
- The first screen. Covered above, and the single most common misapplication.
- Images that are decorative but large. Lazy loading them is fine; not shipping them at all is better. Deferral is not a substitute for weight reduction, the same argument as in hiding an element on mobile.
- Content inside tabs or accordions. Usually a good place for deferral, but check that opening the panel actually triggers the load rather than leaving an empty box — one of the details worth testing in the accordion FAQ element.
- Sliders and carousels. The first slide should load eagerly; the rest can wait. Many components load all slides regardless, which is worth checking before assuming lazy loading is doing anything.
- Print and save-to-PDF. Images never scrolled into view may be absent when a visitor prints the page.
- Scripts that measure positions. Anything loaded through code in the page header that reads element geometry will read it before the images arrive, and the numbers will be wrong.
What lazy loading does not do
It does not reduce the size of anything. A three-megabyte photograph deferred until the visitor scrolls is still a three-megabyte photograph, just paid for later and often on a worse connection than the one that loaded the page. The first-order fix is always the file: appropriate dimensions for where it is displayed, a modern format, and reasonable compression.
It also does not affect whether an image is found by anything reading the page, provided the source is present in the markup rather than only assigned by a script after the fact. That distinction matters for the same reason it matters elsewhere: content that only exists after code runs may not be seen at all. The image referenced by the Open Graph image on a page is a separate matter entirely — it is never rendered on the page and never lazy loaded.
Practical order of work on a funnel page
Fix the files first, then the loading strategy. Resize every image to the dimensions it is actually displayed at, convert to an efficient format, and only then decide what defers. A page whose images are correctly sized often does not need much deferral at all.
Then mark the first-screen image as eager and high priority explicitly rather than relying on the builder’s default, which frequently applies one rule to every image on the page. Check what the platform does automatically before adding your own handling, since two mechanisms fighting is worse than either alone.
Media deserves separate thought. A video is heavier than any image and follows different rules — when a video will and will not autoplay covers what actually governs whether it plays, and deferring the player until the visitor scrolls to it is usually correct where autoplay is not wanted.
Verify on the connection your visitors have
Test on a throttled connection rather than an office one, and on a real phone. The behaviour that matters — whether the first screen appears promptly and whether anything jumps as you scroll — is invisible at desktop speeds.
This matters most for paid traffic. Visitors from a paid social funnel arrive impatient and mostly on phones, and a slow first screen loses clicks already paid for. On a product detail page structure, where several product images sit in sequence, the same discipline applies to the gallery: the first image eagerly, the rest deferred.
If you are unsure whether a change helped, it is measurable rather than a matter of opinion — the method for that comparison, and the reason to judge it on the outcome the page exists for rather than on a score, is in testing a funnel step.
Frequently Asked Questions
Which images should not be lazy loaded?
Anything on the first screen, and especially the main image there. That image is what perceived load time is measured against, so deferring it delays the moment the page appears to have loaded. Everything already visible should load eagerly.
Why does the page jump around when images load?
Because the space was not reserved. The content below sits higher while the image is absent, then moves when it arrives. Reserving the dimensions prevents it entirely and costs nothing but knowing the size — worth doing for every image, lazy loaded or not.
Does lazy loading make images smaller?
No. A three-megabyte photograph deferred until the visitor scrolls is still three megabytes, just paid for later and often on a worse connection. Fix the files first — correct dimensions, an efficient format, reasonable compression — and then decide what defers.
Does lazy loading hide images from search engines?
Not when the source is present in the page markup rather than assigned only by a script after the fact. That is the distinction that matters: content which exists only after code runs may not be seen at all.
What about images in tabs, accordions and carousels?
Collapsed panels are a good place to defer, but check that opening one actually triggers the load rather than leaving an empty box. In a carousel, the first slide should load eagerly and the rest can wait — many components load every slide regardless.
How should the result be tested?
On a throttled connection and a real phone, watching whether the first screen appears promptly and whether anything jumps while scrolling. Both are invisible at desktop speeds, and both are what a visitor arriving from a paid campaign actually experiences.
We build your GoHighLevel account for you
CRM, pipelines, funnels, SMS and automation — configured for your business, not left for you to figure out.
- Setup (one-time)$850
- Ongoing (per month)$38.80
No obligation quote · reply within 1 business day
This site is independently operated and is not officially affiliated with, endorsed by, or sponsored by HighLevel LLC. We do not receive referral commissions — this is our own flat-fee implementation service.