Can lazy loading without dimensions really jeopardize your CLS score?

What makes lazy loading a visual stability issue?

Lazy loading has become a common practice to reduce initial loading time. The browser only downloads images as they approach the visible area (viewport). The problem is: if you do not specify the image dimensions in your HTML code, the browser reserves no space for it.

Concrete result: a temporary gray rectangle or empty space appears. When the image finally loads, it abruptly pushes the content down. A user who started reading a paragraph sees the text jump several hundred pixels. This is exactly what the Cumulative Layout Shift (CLS) measures, one of the three Core Web Vitals metrics.

How does CLS really impact your SEO?

Since the integration of Core Web Vitals as a ranking factor, a poor CLS score can theoretically affect your positioning. In practice, the impact varies depending on your industry and competition. If two pages have equivalent content quality, the one with the better CLS will have an advantage.

But the real cost isn’t just SEO. A degraded CLS frustrates your visitors, increases bounce rates, and reduces conversions. A user who accidentally clicks the wrong link because a button moved at the moment of the click is unlikely to return. Google also measures these behavioral signals.

What’s the difference between native lazy loading and JavaScript?

Native lazy loading (loading="lazy" attribute in HTML5) is now supported by all modern browsers. It is more efficient and simpler than JavaScript solutions. However, it doesn't automatically solve the dimension problem—you still need to specify width and height.

JavaScript libraries (Intersection Observer, LazySizes, etc.) offer more control: custom placeholders, progressive blur effects, adjustable trigger thresholds. They pose the same CLS problem if you neglect the dimensions. Some allow you to automatically calculate the aspect ratio, but it’s better to explicitly define the dimensions in the markup to ensure stability.

• Always specify width and height for every lazy-loaded image, even if CSS resizes them later
• The browser automatically calculates the aspect ratio with these dimensions and reserves the necessary space before loading
• A good CLS (< 0.1) requires fixed or calculable dimensions for all dynamic visual elements
• Modern frameworks (Next.js, Nuxt) handle this automatically if you're using their optimized Image components
• Test with Chrome DevTools by simulating a slow connection (3G throttling) to see actual shifting

Is this guideline consistent with what we observe in the field?

Yes, and it's even one of the most actionable pieces of advice Google has issued regarding Core Web Vitals. Unlike some vague recommendations about "content quality," this is technically verifiable and measurable. Audits of sites with poor CLS almost systematically reveal images without dimensions—this is the number one cause after dynamic ad injections.

Field data confirms: adding width and height to lazy-loaded images often shifts a site from CLS 0.25 (poor) to 0.05 (excellent) without any other changes. The impact is immediate and measurable in PageSpeed Insights or Chrome UX Report. No technical ambiguity here.

What are the limitations and exceptions to this rule?

The problem becomes more complex with responsive images whose dimensions vary depending on the viewport. You can set a fixed aspect ratio (aspect-ratio in CSS) instead of absolute pixels, but this requires server-side calculation if your images are dynamically resized. Modern CMSs (WordPress 5.5+) automatically add width and height, but custom themes or builders can overwrite them.

Another tricky case: user-generated images (forums, marketplaces) whose dimensions you do not know in advance. The technical solution exists—storing the dimensions in the database upon upload, using a default 16:9 ratio—but it requires development. [To verify]: Google has never clarified whether high CLS on UGC content is penalized in the same way as a design issue.

Should you prioritize lazy loading or CLS performance?

It’s a false dilemma. Properly implemented lazy loading improves both LCP and CLS at the same time. By loading only the immediately visible images, you speed up the initial rendering while avoiding shifts if you specify the dimensions. The problem only arises with poorly configured lazy loading.

Some abandon lazy loading for fear of CLS, which is a mistake. On a page with 50 images, loading all 50 at once degrades the First Contentful Paint and the Largest Contentful Paint much more than a dimensioned lazy loading could affect the CLS. The correct optimization is to combine the two: lazy loading for below-the-fold images, explicit dimensions for all.

How can you correctly implement dimensions on your lazy-loaded images?

The simplest and most robust method is to add the width and height attributes in pixels directly in the img tag, even if your CSS resizes the image later. Modern browsers automatically calculate the aspect ratio and reserve the necessary space. For example: <img src="image.jpg" width="800" height="600" loading="lazy" alt="...">.

If you’re using a CMS, check that your theme and plugins do not remove these attributes. WordPress adds them natively since version 5.5, but some premium themes override them with poorly designed CSS or JavaScript. For responsive images with srcset, specify the default image dimensions (src), and the browser will adapt.

What critical mistakes must be avoided at all costs?

The most frequent error: setting width and height to 100% or relative units (em, rem). These values do not allow the browser to calculate the necessary space before loading the CSS. Use absolute pixel values that correspond to the intrinsic dimensions of the image, even if the CSS later resizes it to 100% of its container.

Another trap: images inserted via JavaScript after the initial load (dynamic sliders, Shopify products added to infinite scroll). If these images have no dimensions, they cause post-load shifts that can penalize the CLS significantly. Reserve a container with CSS aspect-ratio or calculated min-height before injecting the content.

How can you check that your implementation is effective?

Use Chrome DevTools (Performance tab) with a slow network throttling (Slow 3G) to observe shifts in real-time. Unstable areas appear in red during the recording. PageSpeed Insights and Lighthouse show the overall CLS score, but do not always detail which image is causing the problem.

For precise diagnostics, install Google Chrome's Web Vitals extension which displays the CLS in real-time while browsing. Test particularly pages with many images (product listings, long blog posts, portfolios). A CLS above 0.1 requires immediate correction; between 0.1 and 0.25 is to be improved, below 0.1 puts you in the green.

• Add width and height in pixels to all img tags, even in lazy loading
• Ensure that your CMS or framework does not remove these attributes during generation
• For responsive images, define a CSS aspect-ratio in addition to HTML dimensions
• Reserve space for containers before injecting JavaScript of dynamic images
• Test on a slow connection (3G) with Chrome DevTools to detect invisible shifts on fiber
• Regularly audit with PageSpeed Insights and correct any CLS > 0.1