Google’s introduction of Core Web Vitals as a ranking signal has put a significant strain on Divi website creators who rely on organic search traffic from Google. Cumulative layout shift has had a lot of those users stumped, and I was one of them.
I found a way to reduce my website’s cumulative layout shift (CLS), reduce total time blocked (TBT), and how to maintain a low score for longest contentful paint (LCP).
Follow these 3 steps to put yourself in good standing, too.
Step 1: Make Responsive Pages, Not Separate Ones
When learning Divi, I was taught to make a desktop version of a page and a separate mobile version inside the visual builder, setting them only to be visible on the appropriate devices.
The problem? This caused a massive cumulative layout shift. On one website, it raised the CLS score to 1.1 in GTmetrix… and Google wants to see 0.1 or lower.
Pro tip: Creating two versions of the same page is also pretty bad for page speed because it forces users’ devices to load both before deciding which one to hide. Creating a single mobile-responsive layout should be a best practice for optimizing all of your core web vital metrics using Divi, not just cumulative layout shift.
I tested out the same page in GTmetrix without the separate mobile version of the page, and—lo and behold—the CLS score dropped to 0.3. It’s still higher than the recommended target set by Google’s Core Web Vital guidelines, but this lowered the score by more than two thirds.
After working on the desktop layout to become responsive for tablet and mobile devices, the CLS score only rose a fraction from 0.3 to 0.34. Clearly it was a huge success.
Now, this sounds easy, but it could take some time if you need to implement this for your top level pages. Divi provides tons of customization options buried in the visual builder’s menus, and you’ll need to fiddle with those on a pretty deep level to get the same content to work on all three kinds of device screens (desktop, tablet, and mobile).
If you’re working with web designs contain overlapping sections or off-set modules, then I have some tips that helped me to reduce my layout shift:
- Do not use padding, margins, or negative margins to shift things around on your page. That creates layout shifts even for basic text modules.
- If you need something off-set, use the “Transform Translate” settings near the bottom of the Design tab (pictured below). This can be changed according to different devices, too!
- Use viewport width (vw) and viewport height (vh) to get the most accurate responsive style. It’s like per cent but for whichever viewport (screen) is displaying the content
- Rows can be set to 100% width or 100vw under Design > Size, if you need to make it full-width on a mobile screen.
- Set smaller H1 and H2 fonts for mobile screens compared to desktop screens. This is under Design, Header Text, and then whichever tab you need (H1, H2, H3, etc.).
- Avoid using custom padding in sections above the fold if you can avoid it, for now.
Step 2: Avoid Divi’s Headers in the Theme Builder (For Now)
On another website of mine, the blog template I used through Divi’s Theme Builder (introduced in the 4.0 release) was experiencing layout shifts. I was surprised to discover this, since had my blog template set up to be as basic as possible:
- There were no fancy effects, like parallax scrolling images across the screen.
- It loaded a single, small hero image (350×250 pixels, rarely more than 30 KB).
- All of my images were below 300 KB.
- Font files seemed to load just fine.
This left me scratching my head, but I wondered if the header had anything to do with it. After saving my header section to the module library (please don’t skip this), I removed it from the theme builder’s Header section for the blog and added it to the Body section instead.
The result? My CLS score dropped from 0.3 to 0.2 on subsequent GTmetrix tests.
Pro tip: Previously, I had a full-width menu module in the header along with my hero image and dynamic H1 text above the fold. I removed the full-width menu module entirely, but it took Divi a few minutes to realize this and repopulate the default menu. Don’t panic if this happens to you—I was staring at a blank white space above my menu for 5-10 minutes, but hiding the Header component in the theme builder increased the Total Blocked Time by 150-250 milliseconds. Just give it a bit of time to put the menu in the proper place.
Future Divi releases might solve the CLS problem of loading visual content in the header (the team at Elegant Themes adds new features and performance upgrades all the time), but this should help to reduce your cumulative layout shift score until then.
Step 3: Find the Right Lazy Loading Settings
Every time I tested a Divi web page in GTmetrix I noticed that images were causing layout shifts by loading last (on every page of every website I managed).
This was driving me nuts because I had tried every conceivable way to set specific image heights and widths within the Divi settings, and nothing worked.
Recently (December 12th, 2020) I noticed that SiteGround had updated its performance plugin to expand Lazy Loading settings. Instead of just toggling Lazy Loading for everything, now it had options to include or exclude specific kinds of images and video files.
A quick intro to lazy loading if you need it: “lazy loading” is a tactic that most performance-savvy website creators use to reduce the time needed for a web page to load on a given device, like a laptop or a mobile phone. It’s supposed to work by delaying the loading of images and video content below the fold until the user scrolls down to them, at which point it loads on the spot. This has allowed websites using visual media (i.e. all of them) to load pages faster in the eyes of users and Google alike.
Two particular settings helped to reduce my cumulative layout shift from 0.2 to 0.12:
- Disable “Lazy Load Gravatars”
- Disable “Fix for Lazy Loading Short Codes”
That reduced my remaining CLS score by nearly half.
Even better? When I disabled “Lazy Load Responsive Images,” my Total Blocked Time (TBT) score dropped from a range 217ms – 244ms to a range of 72ms – 127ms.
That’s the kind of improvement we’re all looking for.
Pro tip: While disabling “Lazy Load Responsive Images” didn’t lower my CLS score any further, TBT is also relevant to SEO. It was introduced as one of the three Core Web Vitals you’ll see in Search Console (along with Cumulative Layout Shift and Largest Contentful Paint). Try to lower it wherever possible.
You might not use SiteGround for your host, of course, but you can use alternate performance plugins for WordPress. Take a look at Jetpack or Autoptimize to see if you can get the same level of control with your lazy loading settings. If those still don’t work out, then it might be worth switching to SiteGround.
The only thing I have yet to solve is the menu in Divi. It still contributes 0.12 to layout shift, but my site’s performance is in good standing regardless. Your Divi website should be better off by following these steps as well. Just give yourself time to test out different settings on your WordPress installation.