Lazy loading can reduce the number of images requested when a WordPress page first opens, but it is not equally suitable for every image. A hero image visible immediately, a likely Largest Contentful Paint image or an image involved in an above-the-fold display problem may need a different loading treatment. When such an image appears late, flashes or does not display as expected, a targeted WP Rocket exclusion can be more appropriate than removing lazy loading from the whole website.
This guide explains how to choose one image, configure an exclusion in WP Rocket, use the no-lazy class and verify the rendered result. The goal is a narrow troubleshooting change, not a universal performance promise. Before and after the change, inspect the markup, clear relevant caches and measure the affected page. The result can depend on the page structure, image dimensions, theme, browser and other optimization features.
Why Exclude Selected Images from Lazy Loading?
Lazy loading is primarily intended for images outside the initial viewport. Those images can often wait until they approach the visible area. Images visible in the first viewport are different: loading them only when they approach the viewport can delay their appearance. This is particularly relevant when the image is the likely Largest Contentful Paint element or is an important part of the first screen.
Targeted exclusion versus global lazy-load changes
A selected exclusion lets you address the image that has a clear reason to load immediately while leaving lazy loading active for other content. This limits the scope of the change and makes its effect easier to test. Do not assume that every above-the-fold image must be excluded, and do not treat an exclusion as a guaranteed Core Web Vitals improvement. An excluded image can create an earlier network request, so the affected page should be measured rather than judged by expectation.
Which Images Are Good Candidates for Exclusion?
Start with the image connected to a specific, observable problem. The decision should come from the image’s position, role and markup, not from a broad rule applied to every image on the site.
Above-the-fold and likely LCP images
Consider a hero image or another image visible as soon as the page opens. A likely LCP image is also a candidate because guidance on browser-level image loading recommends normal eager or default loading for images visible in the first viewport, especially the likely LCP image. This is a reason to investigate an exclusion, not an automatic instruction to exclude every image above the fold.
Check the page at the viewport sizes that matter for the affected layout. If the image is not consistently visible at the initial view, or if it is not responsible for the reported display issue, leave it under the existing lazy-loading configuration until testing shows a reason to change it.
Images affected by a verified conflict
An exclusion can also be considered when an image loads too late, flashes, collapses or participates in a documented above-the-fold display conflict. First inspect the rendered markup. WordPress, the theme, a page builder, a CDN or another optimization plugin may modify image loading independently of WP Rocket.
Use a precise identifier whenever possible. A filename, an image-element class or another exact value is safer than a broad domain, generic class or partial filename fragment that could match unrelated images. Remember that missing dimensions can create a separate layout problem; excluding an image does not automatically reserve space for it.
How to Exclude One Image in WP Rocket
WP Rocket provides an image exclusion field in its LazyLoad settings. The field is described as Excluded images or iframes. The exact label or location can vary with the installed version, theme or page builder, so confirm the wording in the interface you are using.
Choosing the matching value
Begin by inspecting the image’s <img> markup. WP Rocket can target a standard image by its filename or by an attribute found inside the image element. The value should identify the intended image as narrowly as possible. Documented matching options include a filename and values from image attributes such as a class, alt text or title attribute. A suitable custom attribute value may also be used when it is present in the image element.
Copy the relevant value into the exclusion field, then save the setting. If you need to exclude more than one image, enter each exclusion as a separate line. Do not rely on an attribute placed only on a parent element for the standard image-matching method. The identifier needs to be available in the image markup that WP Rocket can match.
For a single image, a filename is often a practical choice when builder markup makes the image class difficult to identify. However, check the actual filename, path and extension in the rendered output rather than typing a value from memory.
Cache handling before verification
After saving the exclusion, clear or regenerate the relevant caches before evaluating the page. Cached HTML, optimized output or other generated files can hide a settings change. Retest the specific page and layout where the issue was observed, including any relevant mobile or desktop version.
Keep the exclusion narrow. If a broad string matches multiple images, replace it with a more exact value before continuing. The purpose is to change the loading behavior of the selected image, not to create an unintended group exclusion.
Using the WP Rocket No-Lazy Class
The no-lazy class is a marker-based way to identify images that should be excluded from WP Rocket LazyLoad. WP Rocket documents a workflow in which no-lazy is entered in the LazyLoad exclusion field and the same class is assigned to each relevant image through its Custom Class field.
This approach can be useful when the image settings provide a reliable way to place a class directly on the image element. It is still a targeted method: add the class only to images that have a clear reason to avoid lazy loading.
Markup requirement for no-lazy
The class must be present on the actual <img> element for the standard workflow to work. A class placed only on a parent wrapper may not be sufficient. This distinction matters with page builders. For Elementor Image widgets, WP Rocket notes that a CSS class may be placed on a parent div rather than on the image element. In that situation, inspect the rendered markup and consider a filename-based exclusion unless another method places no-lazy on the <img> tag.
Do not assume that a Custom Class field has produced the desired output. Verify where the class appears in the rendered HTML before deciding that the exclusion has failed.
How to Verify That the Exclusion Works
Verification should check both the markup and the loading behavior. A saved setting alone does not prove that the browser is receiving the intended output.
Markup and loading checks
Open the affected page and inspect the excluded image in the rendered markup or page source. According to WP Rocket’s troubleshooting guidance, an excluded image should no longer use the lazyloaded class and should load when the page is visited, regardless of its position relative to the viewport. Also check whether the image still contains a loading="lazy" indicator when evaluating the result.
Use the browser’s Developer Tools, including the Network panel, to observe whether the image request occurs on the initial page visit. The image should not wait until it approaches the viewport. Compare the result with the page before the change when possible, but do not treat one browser or one test as representative of every device, viewport, cache state or network condition.
Cache-bypassed comparison
Test the normal cached page and a WP Rocket-bypassed version using ?nowprocket. This comparison helps separate WP Rocket’s output from changes introduced by another system. If the normal page contains lazy-loading indicators but the bypassed version does not, investigate the page’s cached or optimized output. If the bypassed version still contains them, another mechanism may be responsible.
After the markup and Network checks, you can use a performance audit to compare behavior before and after the exclusion. Treat the audit as supporting evidence rather than a universal verdict. The relevant question is whether the selected image now loads as intended and whether the change produces a measured result on the affected page.
Troubleshooting When the Image Is Still Lazyloaded
If the image still appears to be lazyloaded, begin with the exclusion match. Check the exact filename, path, extension or class in the rendered image element. A small difference between the saved exclusion and the actual markup can prevent a match. Confirm that multiple entries are separated by lines and that the intended value is not broader or narrower than expected.
Next, regenerate relevant caches and repeat the test. Check the image on the layout where the problem occurs instead of testing only a different page that may use different markup.
When another system modifies the markup
If the exclusion still has no visible effect, inspect the output with and without ?nowprocket. WordPress, the theme or another plugin may be applying lazy loading independently of WP Rocket. An image optimization system or CDN may also modify the markup. Look for the same lazyloaded class, loading="lazy" attribute or viewport-dependent request behavior in both versions.
Do not attribute every remaining indicator to WP Rocket before checking the complete image element and the systems that generate it. If a builder places a class on a parent container, use an identifier that WP Rocket can match on the image element, such as the exact filename where appropriate. Avoid disabling lazy loading globally unless narrower exclusions fail and the trade-off has been evaluated.
Additional Layout-Stability Checks
Lazy-load exclusion is only one possible part of an image display investigation. If the problem is a shift or collapse while the image loads, inspect whether the browser has enough information to reserve space before the image arrives. Loading behavior and layout dimensions should be treated as separate checks.
Reserve space independently of loading behavior
Missing image dimensions can contribute to layout shifts because the browser may not reserve enough space before the image loads. Check whether the image has width and height attributes or equivalent reserved space in the rendered markup. This remains relevant whether or not the image is excluded from lazy loading.
Review responsive and mobile-specific markup when the issue appears in only one layout. After making the narrow exclusion, measure the affected page again and record why the image was excluded. This makes future template or media changes easier to assess without turning a local troubleshooting decision into a global loading rule.
In summary, start by identifying one image with a clear reason to avoid lazy loading, such as a visible hero, likely LCP image or verified above-the-fold conflict. Use an exact value from the image element in WP Rocket’s exclusion field, or use the no-lazy workflow only when the class reaches the actual <img> element. Clear relevant caches, inspect the markup, test the normal page and the ?nowprocket version, and check for other systems that modify loading. Also verify dimensions, because an exclusion alone does not guarantee layout stability or a performance improvement. Explore our WordPress plugins, WooCommerce extensions, themes and membership plans to find the right tools for your website.