How To Fix The WordPress Gutenberg Image Layout Shift

A while back I’d written about how to reduce your Cumulative Layout Shift (CLS) to zero by loading your site on an ultra-low connection and see what moves around. However, even after getting a CLS of 0 seconds on the Google testing tools, I was still getting a high value in the search console that measures actual, real-world user experience. I was constantly above the 0.10 second limit, and thus had warnings in the console that some of my pages needed improvement. After a lot of searching, I finally figured out that the images in WordPress Gutenberg were the culprit.

Turns out that this is a bug in WordPress that needs to be fixed. But I’m not going to wait around for that to happen, so I found a way to do it manually for my most popular pages.

WordPress Gutenberg Images Missing the “height” Attribute

When you insert an image into WordPress and size it by entering the numerical values on the right-hand side or by choosing a fixed layout, you would expect Gutenberg to supply the exact width and height in HTML. After all, the information is right there in the editor! But it doesn’t do this. Instead, it shows just the width as you can see in this screenshot of my website WP-Tweaks.com where I discuss NameHero’s amazing backups:

Normally, I size the images on my site to a standard width of 550px. It’s a size that fits comfortably on most browser screens, even though the original image size is 1200px. But as you can see, even though the width attribute is included, the height is not. This causes a layout shift when the page is rendered.

Why Include Both Height and Width Attributes?

Most websites these days use lazy loading for images – they’re not displayed until the user scrolls down to see them. However, this means that the browser needs to allocate space in advance so that it can continue to render the rest of the text around the image, while keeping a placeholder for when the image finally makes an appearance.

It can only have this placeholder when it knows in advance what the height of the image is going to be. Otherwise, it’ll keep the height as zero. And if the height is zero, then when the user finally scrolls down to the image, the content layout will shift downwards to accommodate the image height, causing the CLS metric to tick up dramatically!

So this bug in WordPress causes a CLS increase in all posts with images that use lazy loading from any source like the JetPack plugin.

This is a huge problem! Luckily, I found a workaround.

Manually Resizing the Images Causes the Height Attribute to Show

I found that I need to drag the image resizing handle within the Gutenberg editor in WordPress. It doesn’t matter what the final width is – just resizing it by even a pixel is enough:

After making a token resize of the image, simply save the post and load it again. Now the image height is finally included in the HTML code!

As you can see, the height attribute is included. The width has changed by 4 pixels from 550px because I dragged the slider a bit. But this trick causes the browser to be able to properly allocate the space necessary to compensate for lazy loaded images.

I Can’t Manually Change All the Images!

Now you have to repeat this process manually for each and every image you want to fix. I can’t do that on my site – I have literally hundreds upon hundreds of images. So I just did it for a few of my “top” posts that get the bulk of my traffic. After waiting for a day or two for Google to crawl my site, I was rewarded with a green “check” mark in the search console as shown here!

Including the height attribute on the images in just a few of the top posts dropped my median CLS from 0.13 seconds to 0.07 seconds! Far below the threshold of 0.1s as recommended by Google. So now I’m all green, and my site is happy :).

Incidentally, also note my low LCP time of 1.9 seconds, thanks to using Cloudflare’s “Cache Everything” rule with a plugin!