--- title: "Lazy Loading Images in WordPress Blocks" date: 2026-03-20 author: "Imtiaz Rayhan" featured_image: "https://wpblocksuite.com/wp-content/uploads/2026/08/featured-lazy-loading-images-wordpress-blocks.png" categories: - name: "Block Editor" url: "/blog/category/block-editor.md" --- # Lazy Loading Images in WordPress Blocks Lazy-load lower WordPress images that can safely wait outside the initial viewport. Never defer the likely LCP image. Preserve dimensions and responsive source information. Inspect the final HTML because themes and plugins can change Core decisions. ## Understand native lazy loading The HTML `loading=”lazy”` attribute lets browsers defer eligible media requests. The browser chooses when an approaching image should start loading. That distance can vary by browser, connection, device, and implementation. ## Know what lazy loading saves Deferred images can reduce initial network transfers and decoding work. Visitors may never scroll far enough to request every lower image. Savings grow on long, image-heavy pages with substantial offscreen media. ## Know what lazy loading cannot fix It does not shrink files or choose better responsive candidates. It does not reserve space or correct missing alternative text. It only changes when the browser begins fetching eligible media. ## Understand WordPress Core behaviour WordPress introduced native image lazy loading in Core version 5.5. The original [Core announcement](https://make.wordpress.org/core/2020/07/14/lazy-loading-images-in-5-5/) explains its content filtering approach. Core behaviour has evolved since then to protect likely in-viewport media. ## Use Core’s coordinated attributes Current WordPress coordinates loading, fetch priority, and decoding decisions. The [Core loading function](https://developer.wordpress.org/reference/functions/wp_get_loading_optimization_attributes/) returns suitable attributes for supported contexts. Existing attributes and developer filters can change its result. ## Keep width and height attributes Core expects width and height before making important loading decisions. Those attributes also establish intrinsic aspect ratio before download. Responsive CSS can still scale images while preserving their ratio. ## Never combine lazy and high priority `loading=”lazy”` says the resource can wait outside immediate need. `fetchpriority=”high”` says the resource deserves greater relative priority. WordPress warns when one image receives both conflicting instructions. ## Exclude the likely LCP image The [web.dev LCP guide](https://web.dev/articles/optimize-lcp) warns against lazy-loading the LCP image. Deferral adds unnecessary resource load delay to the main loading element. Identify the real candidate across representative mobile and desktop views. ## Do not use fixed fold assumptions Server-side WordPress cannot know every visitor’s exact initial viewport. Headers, notices, device height, and responsive layout change image positions. Use Core defaults, then test important templates and exceptions. ## Inspect Image block markup Open the anonymous page and locate each rendered image element. Check `loading`, `fetchpriority`, `decoding`, `width`, `height`, `srcset`, and `sizes`. Compare attributes with visible placement and measured loading behaviour. ## Check the first content image Core commonly omits lazy loading from early likely in-viewport media. A featured image or header media can affect that sequence. Do not assume the first saved Image block receives one fixed treatment. ## Check featured images Featured images often render through templates outside the post’s block markup. They may appear above headings or below other template content. Inspect template output and actual [LCP](https://wpblocksuite.com/blog/improve-lcp-block-based-pages/) evidence before overriding attributes. ## Check Cover blocks Cover blocks can render image markup or use video and background behaviour. CSS backgrounds do not use the image element’s loading attribute. Inspect actual markup and network discovery instead of relying on block names. ## Check Gallery blocks A gallery near the page top may place several images close to view. Lower gallery items can benefit from browser-managed deferral. Measure request order, visible timing, and scrolling under slow conditions. ## Check slider images The initial visible slide may become the page’s LCP image. Hidden slides can often receive lower priority or later fetching. However, browser lazy logic may not understand plugin-controlled visibility. ## Check carousel preloading Some plugins fetch every slide immediately despite lazy settings. Others store real URLs in data attributes until scripts run. Inspect network requests and HTML. Settings labels provide insufficient evidence. ## Check Query Loop images Repeated post cards can include many featured images below the fold. Lazy loading can reduce initial transfers for later rows. Keep card dimensions stable and responsive candidates appropriately sized. ## Check archive templates Archive pages may use different featured-image sizes and item counts. The first row can contain several visible images on wide screens. Test desktop and mobile separately. One threshold cannot describe both layouts. ## Check comment avatars Long discussions can contain many small offscreen avatar images. Deferring them may reduce unnecessary requests during initial reading. Keep avatar dimensions explicit to prevent late layout movement. ## Check footer logos and badges Footer images are usually far outside the initial viewport. They are strong lazy-loading candidates on normal-length pages. Very short pages can reveal them immediately, so test those templates too. ## Check iframe loading WordPress loading optimisation also supports eligible iframe contexts. Embedded videos, maps, and forms can carry substantial remote payloads. Defer offscreen frames while preserving dimensions and accessible fallback content. ## Do not lazy-load everything Blanket filters can defer logos, heroes, and initially visible thumbnails. They can also override smarter Core context decisions. Prefer targeted exceptions supported by repeatable frontend evidence. ## Avoid duplicate lazy-loading systems An optimisation plugin may add JavaScript deferral beside native loading. The two systems can conflict or delay resources twice. Choose one deliberate strategy. Test it with scripts blocked and enabled. ## Avoid hidden data sources Older JavaScript libraries replace real sources with `data-src` attributes. The browser’s preload scanner cannot discover those resources normally. This is especially harmful when mistakenly applied to an LCP image. ## Keep responsive sources intact Lazy loading should not remove `srcset` or accurate `sizes` information. Browsers still need an appropriate candidate when fetching begins. Inspect selected dimensions and transfer size after scrolling into view. ## Keep image alternatives intact Loading optimisation must not remove or delay meaningful alternative text. The image element should remain in document structure before its resource loads. Test script-disabled and slow-network states with assistive technology. ## Reserve space for deferred images Lazy media still needs stable space before download. Correct intrinsic dimensions let browsers calculate the image’s aspect ratio. Missing space can create [CLS](https://wpblocksuite.com/blog/wordpress-blocks-layout-shift/) when the deferred resource appears. ## Use placeholders cautiously Blurred previews can show approximate content while full images load. They add bytes, markup, styles, and transition behaviour. Measure their benefit and preserve the final image’s accessible alternative. ## Check print and reader modes Deferred images may not load before immediate printing in flawed implementations. Native browser loading usually handles these cases more predictably. Test important printable guides and reader-mode extraction. ## Test slow scrolling Images should appear before visitors reach their reserved regions. Slow networks and fast scrolling expose thresholds that start too late. Native browser heuristics adapt without custom scroll event handlers. ## Test programmatic scrolling Anchor links can jump directly to lower blocks and media. Deferred images should begin promptly without trapping focus or changing context. Test table-of-contents links and browser find navigation. ## Test cached and uncached visits Warm image caches can hide late starts and placeholder transitions. Cold visits expose actual request timing and transfer costs. Record both because field populations include first and repeat visitors. ## Test several viewport heights Viewport height changes which images start inside or near visible content. Landscape phones can reveal fewer initial images than portrait displays. Do not test only one responsive width with one fixed height. ## Check cache and CDN rewrites Optimisation layers can rewrite image tags after WordPress generates them. They may add loading attributes, data sources, or placeholder classes. Fetch the final anonymous response from the production edge. ## Check plugin filters Plugins can short-circuit or filter WordPress loading optimisation attributes. A theme can also provide attributes through image rendering functions. Trace unexpected output to the responsible hook before adding another override. ## Compare with and without deferral Build a controlled staging comparison for the exact page. Measure initial bytes, requests, LCP, scrolling behaviour, and visual stability. Keep image formats, sizes, caches, and network conditions constant. ## Document intentional exceptions Record which images omit lazy loading and why. Include template, viewport, expected candidate, and supporting measurement. Retest exceptions after theme, content, or layout changes. ## Check Custom HTML images Handwritten image markup may bypass normal attachment rendering functions. Core filtering can still modify content tags in supported contexts. Inspect the response and preserve semantics, dimensions, sources, and alternatives. ## Check CSS background images The native loading attribute applies to elements, not stylesheet backgrounds. Background discovery depends on CSS arrival and matching selector application. Do not add JavaScript lazy loading without measuring its complete cost. ## Check picture elements Art-directed images can provide several source elements and one fallback image. The loading attribute belongs on the fallback image element. Keep dimensions accurate for each crop and breakpoint where supported. ## Check attachment replacements Replacing a file can change intrinsic dimensions while retaining older metadata. That mismatch affects reserved space and responsive candidate generation. Regenerate required sizes and inspect representative existing block instances. ## Check image links and lightboxes A thumbnail can load lazily while linking to a larger image. Lightbox scripts may preload full files before the visitor activates anything. Trace both thumbnail and full-size requests in the network panel. ## Check animated images Animated files can be large and require substantial decoding work. Lazy loading defers that work but does not provide motion controls. Prefer efficient video where appropriate and preserve pause functionality. ## Check product galleries Product templates may preload thumbnails, zoom images, and variation media. The main product image can become LCP and should not wait. Test variation changes, zoom activation, and thumbnail navigation separately. ## Check navigation overlay images Hidden navigation panels may contain logos, promotions, or featured cards. They are not initially visible but may need prompt opening behaviour. Test priority and activation instead of assuming normal viewport heuristics apply. ## Check collapsed Details content Collapsed panels can contain media far from the initial rendered view. Browser visibility heuristics may treat hidden states differently across implementations. Test expansion under slow networks and direct fragment navigation. ## Check decoding attributes WordPress commonly supplies asynchronous decoding information for images. Decoding and lazy loading solve different parts of image delivery. Avoid stripping either attribute through broad HTML rewriting. ## Avoid redundant noscript copies Some script libraries duplicate images inside `noscript` fallback markup. Poor rewriting can expose duplicates to crawlers or assistive technology. Native loading keeps real image markup without requiring that duplication. ## Do not preload lazy images Preloading forces early discovery and fetching of a named resource. Lazy loading declares that the same media can wait. Remove conflicting preloads from offscreen images and verify network results. ## Avoid custom scroll listeners Scroll event handlers can run frequently and compete with page responsiveness. They also require threshold, resize, orientation, and hidden-state logic. Prefer native loading unless a measured requirement proves it insufficient. ## Test unsupported or altered behaviour Browsers ignoring the loading attribute still receive a normal image source. That graceful fallback is another advantage over data-source replacement. Test the browsers required by reliable audience and support data. ## Measure complete page savings Count requests and transferred bytes before meaningful visitor scrolling. Then scroll through the complete page and record eventual transfers. Separate delayed work from permanently avoided work in your report. ## Know when deferral loses A short page may contain little useful media outside the initial viewport. Complex JavaScript deferral can then cost more than it saves. This is the honest weak case. Prefer simple native behaviour. ## Use the lazy-loading checklist 1. Open the anonymous public page. 2. Identify likely initial media. 3. Identify the real LCP element. 4. Exclude the LCP image. 5. Inspect loading attributes. 6. Inspect fetch priority. 7. Avoid conflicting instructions. 8. Preserve width and height. 9. Preserve responsive sources. 10. Preserve image alternatives. 11. Test galleries and sliders. 12. Test lower query images. 13. Test fast scrolling. 14. Test cold caches. 15. Inspect CDN rewrites. 16. Document deliberate exceptions. ## Frequently asked questions Does WordPress lazy-load block images automatically? WordPress adds loading optimisation attributes in supported contexts using Core logic. Should the first WordPress image be lazy-loaded? Not when it is likely visible initially or becomes the LCP element. Can an image use lazy loading and high priority together? No. Those attributes communicate conflicting loading intentions. Do lazy images still need width and height? Yes. Accurate dimensions reserve space and support WordPress loading decisions. Should I install another lazy-loading plugin? Only when measured needs exceed native behaviour and the systems do not conflict. ## The verdict Verdict **Defer only safe media:** lower images can save transfers while likely LCP media cannot wait. **Trust rendered evidence:** verify loading, priority, dimensions, sources, and actual requests after every delivery layer. Core provides sensible native image loading behaviour. Audit plugin output equally. Then [compare the $299 lifetime suite](https://wpblocksuite.com/#pricing) when several Pro blocks preserve your loading strategy.