This post and video is not intended by any means to take the place of the official release post and video from Nick Roach and Elegant Themes. However, I usually also release some kind of post and video when Divi has a new feature. The reason I do this is because many of you want to hear from me in my own words what the update is all about and offers some different perspective. I hope you enjoy!
Join subscribers on our YouTube channel and enjoy other Divi video tutorials!
Before You Update
This should go without saying, but I need to remind you!
Always create a backup before updating a plugin or theme
Always create and use a staging site to test the update first
Always clear all your cache after updating
I also recommend waiting until a few x.x.x updates after the main x.x update. This allows the team to fix commonly reported bugs. This usually means waiting a week or two to update your lives sites.
Always do the normal troubleshooting steps before contacting support
Do You Still Need Optimization Plugins?
A lot of people are already asking questions such as, “Are plugins such as SG Optimizer or WP Rocket are still needed?” You need to keep in mind that Divi is only part of your website. You also definitely need caching and a Content Delivery Network (CDN) enabled. Those things are outside of Divi and not relevant to it, and should always be used in combination with the performance optimization features that Divi has built-in. As a general rule of thumb, you should never have two plugins or settings doing the exact same thing, and this is actually less of a factor now that they removed the settings for Minify and Combine JS and CSS. Elegant Themes tested the new features with all the most popular performance plugins to help identify conflicts before releasing it, so in general you should be fine continuing to use your favorite caching and optimization plugin and especially a CDN.
Testing, Testing, 123
What good is a lot of technical talk and hype without real-world results, right? I was going to give you some of my own test results, but I decided it was going to get way overwhelming. There are so many scenarios and factors that it would just get crazy complicated. Instead, I want you to go test. Run some tests in Google Pagespeed Insights and GTmetrix before and after you update. Or install the update on your staging site and compare various pages on the site.
My Personal Test Results
Hemant and I have tested many sites in the last week. Every single page we test is certainly better. How much better depends on a lot of factors! Please keep in mind that Divi is a theme, and is totally reliant on good solid hosting, a good quality CDN, and proper caching. Simple standard Divi websites are pretty much perfect, it is so exciting and awesome. When you move into Theme Builder templates and WooCommerce and other things like that, there is still some room for improvement. But in general, we tested a lot of scenarios including huge ecommerce stores and blogs, and all of them were much better with the new Divi update.
Test Sites Created By Elegant Themes
You probably noticed that Divi now has a public test page for you to run your own tests. They also have test sites for other popular themes, and below is a list of the ones that I have found (there may be more that I missed or more added in the future).
Gutenberg & Astra
Beaver Builder & Gutenberg
New Performance Settings In Theme Options
The biggest changes in the new 4.10 update is in the Divi Theme Options. Previously there was the General tab, but now they have added the new Performance tab. Let’s take a close look at what changed in each of these tabs.
This is the newly added tab in Divi Theme Options and contains a lot of new settings. Everything you see in this screenshot is new in version 4.10. Below you will find the description of each setting and our explanation. As you can see, most of the settings are enabled by default.
Dynamic Module Framework
Prior to this update, all the code functionality related to every single one of the more than 50 default modules was being loaded on every page that was using the Divi Builder. This means that even if you were only using a few different modules, it was actually loading assets and code for all of them. This kind of behavior naturally affected the overall speed of the page, and it is now resolved with a new feature called the Dynamic Module Framework. The new logic feature processes what is needed and will only load functions for module types that are actually used on the page, and will not load any additional bloat at all.
Similar to the previous setting, this new Dynamic CSS feature means Divi will only load CSS that is actually used on any particular page. In the past the Divi stylesheet was infamously huge at 860kb, and it was known to crash computers when trying to open it. You may think that sounds small because it is lets than a megabyte, but think again! This was huge for a stylesheet which are usually very tiny. It was due to everything related to Divi being in one file. Things like styles for the builder, the design settings, WooCommerce, and every module were in this one file.
But now it is dynamic, meaning it will only load the necessary code per page depending on what is needed. Now the file size is about 94% smaller down to 54kb! This dramatic decrease is thanks to a smart new system that breaks the code into segments that intelligently combine into a special stylesheet that provides only the necessary styles needed for the elements on each page.
As you probably know, Divi has its own ETModules icon font build directly into Divi. This is great, and it is even teased to be in for an update soon! In previous versions, all of the icons in the entire set would load on the page even if you were only using one, such as in the Blurb module or toggle module or any other module with icons. The new update creates the same dynamic functionality as we discussed with CSS and modules, only loading the icons or subset of icons that are actually used on the page instead of all of them.
Load Dynamic Stylesheet In-line
This setting takes the stylesheet and dequeues it, meaning it removes it from the list of items that need to render before the page content can be fully loaded. It then prints the CSS inline, meaning it embeds the CSS into the header of the page. This allows the page to load only the needed CSS to render the design above the fold (the part of the screen you first see when the page loads). The advantage is that now the main stylesheet does not need to wait in line to be loaded, and this removes a render-blocking request and improves Google PageSpeed scores. Another advantage is that now the page will not cache the stylesheet. But don’t worry, the Divi stylesheet is now so tiny that it will surely not matter at all, and this should actually be helpful as you design with Divi.
This setting allows Divi to identify what CSS styles are needed in order to properly display the first part of a web page in the visible viewport. As the name suggests, this code is referred to as Critical CSS because it is the process of taking the bare minimum CSS you need to display content above the fold when the page loads. In other words, Divi will now automatically separate critical and non-critical styles. Code that is needed will be applied inline. And code that is determined not to be needed for that area is deferred and not loaded, which drastically reduces the number of styles needed during the initial page render. This allows the content to show up instantly because you no longer need to wait in line for the stylesheet to load first. This is a huge advantage and something Elegant Themes and all of us users should be proud to have in Divi.
Critical Threshold Height
In the previous few settings, we talked about the area of the page that is “above the fold” or the area that is seen first on your screen. Here we are referring to this visible viewport area as the “threshold height” which is a relative term for estimating the size of this area. There are three threshold height options to choose from including Low, Medium, and High, with it set to Medium by default. So if you set the height to Low then the maximum amount of CSS will be deferred and if you set the height to High then the minimum amount of CSS will be deferred. It is important to understand that this area is a bit relative, and not clearly defined due to all the different size devices. If you load the page on a tall monitor as apposed to your phone in landscape mode, then the threshold will be quite different. If you set this to High, then the line defining the boundary of the height will be higher and fewer styles will be deferred. But that may be a good thing, as this reduces the chance for elements on the page to move during the render. This is called Cumulative Layout Shift (CLS) and is a hot topic these days. Elegant Themes notes that if you are experiencing CLS issues, you can increase the threshold height. In my tests, setting this to High lowered my CSL score.
Disable WordPress Emojis
This is a simple feature that dequeues ore removes the Emoji styles and scripts for better performance. Believe it or not, WordPress actually enqueues the emojis into the core, so this feature is like an undo button for that. But don’t worry, this is almost never needed because modern browsers support native emojis, making the WordPress’s emojis unnecessary in most cases.
Defer Gutenberg Block CSS
The concept of this feature is very similar to some of the other settings here, but with a slight difference. If you enable the Divi Builder on a page and are not using the Gutenberg block editor, then there is no need to load any CSS styles for Gutenberg. Divi handles this by moving the Gutenberg block CSS file from the header to the footer. This actually means it will still load, but it will be more like lazy-loading. It is not part of the initial page load, so therefore it is no longer a render blocking resource.
Render blocking resources are all the files that are vital to the process of rendering a web page. A render blocking resources causes the browser to stop downloading the of the resources until these critical files are processed. This unfortunately delays the entire rendering process. When a render blocking resources is deferred, it naturally improves performance.
Improve Google Fonts Loading
There are several improvements to how Divi handles Google fonts. In the past, Divi needed to make a slow 3rd-party request for the fonts and this would lower the page load time because it was loading so many styles and sizes that were not needed. The great news is that Google fonts will now leverage browser caching, meaning it will utilize a static version of the fonts locally when possible. The browser is now instructed to leverage any previously downloaded fonts locally rather than from the network. The fonts that are needed on the page are loaded inline, which eliminates the render-blocking request and now the page can be loaded faster.
Limit Google Fonts Support For Legacy Browsers
Another small Google Font improvement is the reduction in the file size that is needed when very old legacy browsers are used. This is achieved by removing some legacy font files, which slightly reduces the load. You can turn this off to increase support for older browsers, but I would leave it enabled as it doesn’t make much difference in the speed.
Defer jQuery And jQuery Migrate
Enqueue jQuery Compatibility Script
This is a safeguard feature that serves as a way to make sure that all third party scrips are properly enqueued. Due to the other JS deferral settings, it is possible that some scripts could break. In that case, you will see errors in the browser developer tools in the Console tab. If you do see these errors, then make sure this setting is turned on because it will attempt to solve the issues. If everything is fine with it off, then that is great.
Defer Additional Third Party Scripts
This setting shifts the jQuery scripts registered in plugins and themes to the body to improve the performance. This functionality is disabled by default, and keeping it disabled may be wise in most cases because this can cause serious JavaScrip errors on the website. Again, if you face some issue, it is best to let Elegant themes know, so they can address it properly.