Image Lazy Loading and LCP: Don’t Let Images Slow Down Your First Screen

Ever had this experience: you click into a page, text comes out, but the big image at the top of the fold won’t load for ages, the whole page just keeps spinning. I’ve taken over quite a few sites like this — check the performance panel, and the problem almost always comes down to images. Images are usually the heaviest part of the first screen; handled badly, LCP gets dragged down, and rankings and bounce both suffer along with it.

And lazy loading — used right, it’s an accelerator; used wrong, it delays even your above-the-fold images and backfires. Today let’s get the math straight between images and first-screen speed.

How lazy loading works and how it gets misused

The idea of lazy loading is simple: images below the fold aren’t loaded first, they’re fetched when the user scrolls near them, saving first-screen traffic and speeding up first paint. This is a good thing, but lots of people apply it blanket-style to all images (including the big above-the-fold one), and as a result the very image that decides LCP gets delayed — slower, not faster.

Remember this boundary line

The correct boundary: key images inside the first screen, above the fold, must load immediately without conditions; only images below the fold that users can’t see yet get lazy-loaded. Cross this line wrong and optimization becomes negative optimization. When verifying, focus on whether the LCP element got blocked by lazy-loading logic — that’s the most common and most hidden pitfall.

Never lazy-load above-the-fold images

LCP is usually decided by the biggest image or content block in the first screen. If it “waits for scroll” because of lazy loading, LCP time spikes and the core metric goes straight over the limit. So hero images and main visuals must be excluded from lazy loading — let the browser request them the moment it parses, showing them to users and crawlers right away.

Implementation-wise, give above-the-fold images native loading=”eager” or simply don’t mark them lazy, and make sure no deferred script blocks them. Many frameworks default to site-wide lazy loading, so you need to manually “give green light” to critical images. Listing out a “first-screen image list” and handling it separately is the most direct way to avoid collateral damage — same thinking as “critical content reachable first” in flat site architecture.

Pick the right format and compression

The same image, WebP is about 30% smaller than old formats, AVIF even more aggressive — hard to tell apart by eye yet saves lots of bytes, directly lightening the LCP load. Stack lossy compression to “just clear enough,” and volume drops further. Format and compression are the two things you should do first for image speed, almost no visual loss.

Batch-processing historical images and forcing format conversion and compression at upload prevents new images from piling volume back on. Keep original backups to avoid irreversible compression loss. Image slimming is an extremely high-value action — its contribution to LCP is often immediate, more practical than obsessing over advanced loading tricks. Do it thoroughly first.

Dimensions and responsive images

Using a 4000-pixel image to display at 400 pixels is classic waste: the browser downloads the big image first, then shrinks it, spending extra traffic and time for nothing. Use responsive images (different sizes per device), so phones get small images, desktops get large ones — each takes what it needs. LCP benefits especially on weak-network phones, and the experience difference is obvious.

Pair this with setting width/height attributes on images, letting the browser reserve space in advance and avoid layout shift (CLS) when images load and push content around. Dimensions and stability are a combined move: lighter load and no wobble. Many sites only compress volume and forget dimensions — LCP improves but CLS breaks, metrics trade off against each other. You have to take care of both.

Preload critical images

For the above-the-fold image that decides LCP, use preload to tell the browser “this one first,” letting it fire the request early and jump ahead of other resources. Especially when an image is referenced indirectly by CSS or scripts and the browser discovers it late, preload can compress the waiting time dramatically — a precision tool for tuning LCP.

Preload must be precise, only for truly critical images; over-adding grabs bandwidth from other resources and backfires. Combined with inlined critical CSS and prioritized critical requests, first paint time pushes forward even more. Same logic as crawl budget optimization: direct limited resources (here, bandwidth and priority) to the single element that most affects the result.

How to verify

Use the performance panel’s LCP marker to confirm which image and when it painted; use Lighthouse to see whether the “defer offscreen images” suggestion still points at above-the-fold images. For field data, look at CrUX’s P75 of real-user LCP — passing should mean most visitors, not the best batch. Keep the acceptance bar steady.

After changes, compare horizontally: above-the-fold image size, load timing, whether it’s still hit by lazy by mistake. Treat LCP as a continuously monitored metric, because changing images or redesigning all move it. The relationship between images and first screen looks simple, but get a detail wrong and it’s counterproductive. Periodic review is more reliable than one-shot tuning, and it catches rebounds from later changes too.

Coordinate with overall speed

Image optimization isn’t an isolated item; together with fonts, scripts, and caching it decides first-screen speed. Only compress images without controlling scripts, and LCP still gets held back by long tasks; only lazy-load without compressing volume, and what you save is limited. Put images into the overall speed plan, decide what to do first and later, ordered by contribution to LCP — then resources are spent where it counts.

A practical priority: first make above-the-fold images load immediately and stay small, then lazy-load and convert formats for non-first-screen images, and only finally pick at scripts and fonts. Layer by layer, you see LCP drop at each step. Images are the biggest chunk — often this one item solves most of the problem — but don’t ignore the rest because of it; overall coordination is what truly makes the first screen fast and stable.

Common misconfiguration reminders

Besides above-the-fold images getting lazy-loaded, another common pitfall is preloading decorative small images too, grabbing bandwidth and slowing the critical image instead; or scaled-down images still carrying huge pixels, making compression pointless. When verifying, check each LCP element’s actual downloaded size against expectations — don’t be fooled by the word “compressed,” confirm the live site is really serving small files.