How to Fix Cumulative Layout Shift and Core Web Vitals for Divi 4.0 and Higher

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).

Update: Divi 4.10 Solves Most Core Web Vitals by Default

On August 18, 2021, Elegant Themes released a major performance update called Divi 4.10 (but not “5.0,” strictly speaking). It addresses most performance issues that users had experienced in the past and, as far as I can tell from installing it on 3 separate sites, actually does an excellent job of putting your Core Web Vitals score in the green.

Here’s the announcement video from Nick Roach, the founder of Elegant Themes.

You can also read about it, but here are the highlights:

• Only the modules used on the page are loaded, instead of everything at once.
• Only the CSS needed is loaded instead of everything.
• Divi only loads Javascript needed for the page (excluding third-party JS, like Tag Manager).
• Critical CSS is a built-in feature now (this is a big one).
• Duplicate styles have been eliminated to reduce the number of style sheets loaded.
• The Gutenberg block editor is deferred until the page you actually built is done loading.
• In-line style sheets remove a render-blocking request (also important for the TBT metric).

This helped to solidify my Core Web Vitals stats across the board, but there were a few speed bumps to work out first. Make sure you keep these on hand while updating your site—and of course, back up everything first in case your site experiences issues afterward.

First, disable all other performance plugins, including cache-related ones. I run the SiteGround Optimizer plugin on my sites and, while I’ve kept it enabled, I’ve switched off almost all of the optimization options. Divi will do most or all of that by default now and instructing a plugin to make the same optimizations could actually backfire on you.

Be sure to disable everything first. If you think there’s still room for improvement, then try enabling stuff like this one at a time and re-testing performance through GTmetrix.

Remember: If you have a plugin that provides critical CSS (like Jetpack Boost, something I recommended before this update), then disable that as well.

Here’s why: Divi 4.10 has expanded performance options and created an entirely new sub-menu for them. These are designed to make the most of Divi’s unique structure, so start with these first.

I found that the optimal setup on my Divi sites happened when I disabled just one option in the menu pictured above (“Dynamic Icons”), and then disabled 3rd-party performance plugins. Divi just took it from there.

Here are the test results for all three of my websites now running Divi 4.10.

I had to use the SiteGround plugin to add some minimal performance enhancements to the third website (this one, actually), but Divi 4.10 takes care of most optimizations by default. This is incredibly promising, folks!

Note: All three of these sites run on the same SiteGround plan.

If you’re running an older version of Divi, then continue reading for the previous solution to fix your Core Web Vitals.

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.

Yikes.

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:

1. Do not use padding, margins, or negative margins to shift things around above the fold. That creates layout shifts even for basic text modules.
2. 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!
3. 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
4. Rows can be set to 100% width or 100vw under Design > Size, if you need to make it full-width on a mobile screen.
5. 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.).
6. 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:

1. Disable “Lazy Load Gravatars”
2. 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.

Step 4: Add Critical CSS

I ran into even more core web vital problems for Divi on another website that I manage, but I managed to get all of them into the green. even with a more complicated website than the one I’ve detailed above.

Here’s the proof:

This came down to two core actions:

1. Disabling performance plugins and performance features from Divi itself to avoid conflicts.
2. Enabling the Critical CSS feature through the Swift Performance Lite plugin.

Disable Performance Enhancements Before Proceeding

At first the website had a 0.4 CLS score, which was 0.3 higher than what Google wants to see.

The first thing I did was deactivate excessive performance plugins and features, as mentioned above. In this website’s case, the Autoptimize plugin was overlapping with two performance features within Divi. I cut down the Total Blocking Time (TBT) down to 84ms just by deactivating the plugin, but the CLS score was still 0.4, as you can see above.

Trying to see what happened when I deactivated everything, I turned of Divi’s two main performance settings in the options.

1. Minify and Combine Javascript Files
2. Minify and Combine CSS Files

This reduced my TBT score to 0 and brought down my CLS score to 0.02, but it raised by LCP (Largest Content Paint) to 2.4 seconds. LCP is the time it takes to load the largest content element above the fold on your page (often images). As you can see, GTMetrix’s overall performance score plummeted because of that. Speed is still important!

That’s when I could see exactly how much time was saved by the performance-enhancing settings—they cut my Largest Content Paint time in half, by 1.2 seconds. Good to know, right?

Depending on your setup, you may wish to turn on your settings again. However, I’d urge you to keep them off for the next step. The plugin I used to generate Critical CSS also carries out a wide range of performance enhancements for WordPress, and it can create conflicts with hosting providers, themes, and other plugins somewhat easily.

Installing Jetpack Boost for Critical CSS

After trying a few solutions, I found Jetpack Boost to be the best solution for generating critical CSS on my divi websites. It’s a new plugin from Automattic that can operate on its own to improve your website’s technical performance and core web vitals right out of the box. It shares the brand name with the original Jetpack plugin, but you don’t need the original for this to work.

Here’s why I’d recommend it:

1. The plugin is free.
2. It’s made by Automattic, one of the teams behind WordPress itself.
3. It’s simple and light-weight.
4. It doesn’t require the original Jetpack plugin to work.

It doesn’t look like much at a glance, but Jetpack Boost is an incredibly useful plugin for Divi. It sports a clean, minimalist layout with just three key settings:

1. Optimize CSS Loading
2. Defer Non-Essential Javascript
3. Lazy Image Loading

Again, make sure you don’t have performance conflicts between this plugin and something else (like another plugin or the theme itself), but at least turn on the “Optimize CSS Loading” setting. It can take 5-10 minutes to complete, so it’s worth stepping away to make a coffee or something while you wait.

Alternative: Installing Swift Performance Lite for Critical CSS

Update: Swift Performance Lite started causing issues on my client’s production website after extensive and successful testing on the staging environment. Background images set in Divi sections (the blue containers in the visual builder) were not showing up, so I was forced to find an alternate solution with the new Jetpack Boost plugin, covered above.

The way Divi is built can cause massive layout shifts (which you’re probably painfully aware of right now), and this is the best explanation I’ve read on the subject:

“Out of the box, styling of Divi elements can be achieved in one of three ways, each coming into play further down the DOM. They are:

1. Divi default css style sheet – loaded in the head (near the top) of your document which provides initial style settings for every element on the page.
2. Divi-> Theme Options -> Custom CSS (admin panel Divi menu). Rules added here are saved to the database and output as a block of code just before the body opening tag. Because they are further down the DOM, these take priority over the default css style sheet settings declared in #1.
3. Inline styling – these are created whenever you adjust a module’s default settings (ie adjusting margins/width/font sizes etc) or apply custom css via the module’s advanced tab. The values are stored in your database and are applied directly to the element in the DOM. Because these are output further down the DOM, and at the time of element creation, they take final priority over the styles declared in 1 & 2 above.”

– Lee Kierstead, Studio 6AM

This means that Divi loads the default content, unstyled, and then applies styling afterward. Even though I had spent countless hours setting maximum widths on various modules, it didn’t help my CLS score because all of that styling data was stored inline—the third source for CSS that Divi uses, not the first or second.

• That is why large layout shifts occur in Divi by default.
• That is why using the Divi builder to set sizing doesn’t help (inline CSS is called on too late!).
• That is why your CLS score might have even worsened while trying to fix things inside the builder.

This is where critical CSS comes in. It loads everything on your page above the fold, including styling from your cascading style sheet (CSS). You can find various services and plugins that perform this, but the Swift Performance Lite plugin provides this feature free of charge. That’s why we’re using it.

Note: This plugin caused a conflict with my WordPress installation at first, but I found a way around it. I think it was an automatic GZIP feature that conflicted with the same feature from this website’s hosting provider, WP Engine. Neither WP Engine nor Swift Performance Lite had an option to turn off GZIP compression, unfortunately, but I got them to work together by disabling the Minify HTML and Lazy Load options in SPL’s settings.

With that out of the way, follow these plugin settings before trying anything else:

• General: Leave everything turned off.
• Media/Images: Leave everything turned off.
• HTML: Make sure “Minify HTML” is turned off, or else it will break the site.
  • Smart Render is inaccessible to us in the Lite (free) version of the plugin, but in case we have a paid version in the future: leave it turned off.
• Scripts:
  • Turn on Merge Scripts
  • Turn on Minify Javascripts
  • Turn on Separate Scripts
• Styles:
  • Turn on Merge Styles
  • Turn on Generate Critical CSS
  • Turn on Separate Styles
  • Set Minify CSS to Basic.
  • Leave everything else turned off. Do not not add any additional critical CSS either.
• CDN: Leave everything turned off (we already run a CDN through WPE, our hosting provider).
• Don’t touch the Export/Import settings either.

Having done all that, the Divi website achieved excellent speed and core web vitals.

• Largest Content Paint: 1.1 seconds
• Total Blocking Time: 0 milliseconds
• Cumulative Layout Shift: 0.11

The only thing I have yet to solve is the menu in Divi. It still contributes 0.11 to layout shift, but both of the websites detailed here have performance 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.

Good luck!