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: While I haven’t solved the Divi menu’s last 0.11 CLS, I have found a way to use critical CSS to help reduce CLS even further if the first three steps didn’t help you. You can read it in Step 4!
Follow these 4 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 above the fold. 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.
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:
- Disabling performance plugins and performance features from Divi itself to avoid conflicts.
- 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.
- 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:
- The plugin is free.
- It’s made by Automattic, one of the teams behind WordPress itself.
- It’s simple and light-weight.
- 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:
- Optimize CSS Loading
- 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:
- 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.
- 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.
- 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.”
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.
- Turn on Merge Scripts
- Turn on Separate Scripts
- 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.