If you have been blogging for a while, chances are you have a few posts that are basically photo essays: a travel recap with forty vacation shots, a recipe with step-by-step process photos, a product roundup with a gallery for every item. These posts are great for readers, but they are rough on page speed — because by default, WordPress asks the browser to fetch every single image the moment the page loads, whether the reader ever scrolls that far or not.

Lazy loading fixes this, but the interesting part is not lazy loading in general — it is what happens when it gets applied correctly to a post that already exists, with images that are already embedded, already sized, and already indexed by search engines. That is a different problem than lazy loading a brand-new page, and it is worth understanding on its own.

The problem with old, image-heavy posts specifically

When a post was published, WordPress had no way of knowing which images would end up “above the fold” (visible without scrolling) versus buried three galleries down. So every <img> tag was treated the same way: load it now, load it all, load it as fast as the browser can manage.

For a short post with one featured image, that barely matters. For a long-form gallery post or an old archive page with dozens of embedded photos, it means the browser is competing to download images a reader may never see, while the images that actually matter — the ones visible in the first screenful — have to fight for the same bandwidth.

The result is usually a slow-feeling page: the visible content takes longer to settle, and Core Web Vitals metrics like LCP (Largest Contentful Paint — the moment the biggest visible element finishes rendering) suffer, even though most of the “wasted” loading is happening for images the reader hasn’t scrolled to yet.

What correct lazy loading actually does, image by image

Lazy loading is not an all-or-nothing switch. Applied properly, it treats each image in a post according to its position on the page:

• Above-the-fold images load eagerly. Anything visible in the initial viewport — a featured image, the first photo in a gallery, an image right under the headline — is fetched immediately, with no delay. Lazy-loading these would actually make the page feel slower, so they are deliberately excluded.
• Below-the-fold images get loading=”lazy”. Everything further down the post — image six of a twelve-photo gallery, the diagram halfway through a tutorial, the comparison shots near the end of a review — is marked so the browser defers fetching it until the reader scrolls close to it. The browser handles the actual timing natively; the image simply is not requested until it is about to matter.
• The page’s LCP image gets priority, not lazy treatment. Every page has one element most likely to be its Largest Contentful Paint candidate — often a hero image or the first content photo. That image is not just loaded eagerly; it is flagged as high priority so the browser fetches it ahead of less important resources competing for the same connection.

This three-way split is the part that is easy to get wrong by hand. Mark too much as lazy and you can accidentally delay your own LCP image, which actively hurts your Core Web Vitals score. Mark too little as lazy and you lose most of the benefit on long pages. Getting the boundary right — image by image, based on actual position in the rendered page — is what makes the difference.

Why this matters most for archives and galleries

The benefit of correct lazy loading scales with how image-heavy a post is. A single-image blog post will barely notice a difference. But think about what a browser has to do on a long-running archive:

• A photography portfolio page with 50 embedded images
• A recipe blog’s “process gallery” posts with 15–20 step photos
• An old product comparison post with screenshots for every item
• A yearly recap or “best of” roundup post

Without lazy loading, the browser queues up every one of those images for download as soon as the page starts rendering — even the ones at the very bottom of a page nobody may scroll to. That competes directly with the images and styles needed to paint the visible screen. With correct lazy loading in place, the browser’s early bandwidth goes toward what the visitor can actually see, and the rest loads on demand as they scroll. That is a direct, practical improvement to both LCP (how fast the main content appears) and general time-to-interactive, because the browser simply has less to do up front.

This is exactly the kind of post where the fix matters most — and, not coincidentally, exactly the kind of post people forget to revisit once it is published and ranking.

How this fits into optimizing your existing content

This is where older posts need a slightly different approach than new ones. A post you are writing today can be planned with performance in mind from the start. A post from three years ago was not — and going through your archive by hand, post by post, to figure out which images are above the fold and which are the LCP candidate, is not a realistic task for most site owners.

This is one of the things AWP handles automatically when you run a personalized optimization on existing content. AWP looks at the actual rendered layout of each page and works out, image by image, what should load eagerly, what should be marked loading=”lazy”, and which single image is the LCP candidate that deserves priority. It applies that result directly in your own WordPress media library and at serve time — nothing about your original post content is changed, and the optimization is fully reversible.

Combined with AWP’s image and CSS handling — right-sized AVIF variants and critical CSS delivery — this means an old, image-heavy post can get the same loading behavior a newly built, performance-conscious page would have, without you needing to manually audit a gallery post from 2021 to figure out which of its forty images actually matter first.

If you have a backlog of long posts or galleries sitting in your archive, that is exactly the content where fixing image loading behavior pays off the most.