Today, 40% of the web is powered by WordPress, and according to Builtwith.com there are 2 million active websites using Divi. That makes Divi the most popular WordPress theme of the most popular content management system. It’s surprising to realise Divi is more popular than every free theme, even the default WordPress theme.
I don’t usually post about specific website building tools but ET (Elegant Themes, the company that owns and develops Divi) is focusing a lot of energy on some powerful new improvements to Divi. In this blog post, I’ve collated the newest updates from CEO Nick Roach, published in various places. I hope this post becomes irrelevant very soon as these features are released into the wild.
So let’s have the big news first – a fundamental rebuild of the visual builder.
Google’s old lighthouse report provided a list of code-focused suggestions that people could work through to speed up their sites, but often websites are slowed down by more fundamental issues like having a decent host, good caching and implementing a CDN. The choice of theme rarely has the biggest impact on site speed but there are still plenty of things that can be done within Divi to serve content more efficiently.
There’s a concern that as ET adds more features the whole system will get more and more bloated. We can define bloat as “things I’m not using that affect me negatively,” so the aim is to completely strip everything unnecessary from every Divi-built page.
1. Dynamic Module Framework
Divi currently has 54 modules (and will be adding some more WC modules soon) and a big bunch of design options. When Divi renders a page, it has to “be aware of” all of those features, even if they aren’t in use. The new Dynamic Module Framework will change that, completely cutting out all unused features on the fly. If you build a page and only use 4 modules, the page builder won’t process the other 50 modules you aren’t using. It’ll do the same with design features too so if you aren’t using motion effects, box shadows, sticky options etc, the framework won’t process the logic for those either.
This feature is already built and will be entering quality testing soon. On ET’s QA servers this feature reduced the (presumably uncached) TTFB all the way down from 2000ms to 500ms.
This really is a form of caching, so even sites that aren’t cached will be slightly taken care of by Divi when it comes to CSS and JS. It will be up to you how fast and lean you want your pages to be.
2. Dynamic Assets
This same logic will be applied to Divi’s CSS and JS files. With this update, only the CSS and JS needed for each module in use will be loaded. The same thing will apply to the theme options too, so if you’re not using the slide-in menu or smooth scrolling, the code for those options won’t be loaded.
This feature takes Divi’s 850kb style.css file and brings the base file size down to 55kb. The dynamic CSS required to build this layout, for example, has been reduced from 850kb to 200kb.
This is a very tricky feature that ET has been working on for over a year and it’s getting pretty close to being finished. However, we can expect QA testing to be quite rocky due to how much CSS ordering has changed, so be patient and test it well on your site once it’s released.
3. Critical CSS
The idea of setting critical CSS is that you can greatly improve the page rendering speed if you only put the CSS in the <head> that’s required to render the content above the fold. The rest of the CSS is then placed in the <body> and is loaded along with the rest of the page’s content. The bulk of the CSS loaded in the <body> is not render-blocking.
Once all Divi’s CSS is broken up into chunks thanks to Dynamic Assets, the framework can intelligently package only the Critical CSS in the <head> and put the rest in the <body>. Core Web Vitals is going to love how little CSS is in your page’s header as it will speed up the page load without causing any UI issues. It will be rare to find a theme that can implement this as well as Divi should be able to.
These major updates to the visual builder are part of a plan to respond to Google’s new Core Web Vitals requirements. However, their rollout will be staggered. Discussing these updates in a recent podcast Nick said “a lot of these features are getting pretty close to being finished, all within 1-3 months”. However, that probably doesn’t apply to the more fundamental Divi Foundation update.
4. The Divi Foundation update – no more shortcodes
Divi currently stores all page content as shortcodes. However, shortcodes are a difficult way to handle and retrieve data and cause a bunch of little problems nearly impossible to fix, like escaping issues. They’re a bit hacky. WordPress is also moving away from a model in which custom rich content is primarily handled with shortcodes towards their new blocks format, so it makes sense for Divi’s builder to become more concordant with this new Gutenberg blocks format.
This doesn’t mean that Divi is becoming part of Gutenberg. In future, it may be possible to insert Gutenberg blocks into a Divi page but that’s at the mercy of what WordPress allows as blocks continue to be developed and won’t be the focus. This is about switching to a better data storage format that is congruent with the future of WordPress.
The way Google Fonts are loaded will be improved and it’ll be possible to clear out some unnecessary CSS and JS. With this new storage format, most of Divi’s module output will be inherently cached with no processing necessary on the front end, leading to some amazing performance improvements, even without a caching plugin and on dynamic pages.
This is a big project and will take a while. ET will be completely revamping the module API (though it’ll still be REACT based), making every part of it completely extendible. This will open the floodgates for much deeper third-party development and plugin integrations. Nick explains: “right now it’s like we’ve opened little doors to our builder so developers can create a module and Divi will spit out a modal, then you can add whitelisted fields. It’s a very formulaic process to creating a module. It makes things simple but a little too rigid. The new idea is that we’ll be using our own API to build everything you see so you’ll be able to do that as well.”
He also says “I’m confident in [these updates] but I don’t know how they’ll end up being released.” ET started hatching these plans a year ago and started development 4-5 months ago, and they reckon it could be a one year project to fully create and test the new API. This will lay the foundation for a whole new vision for the visual builder itself(!) a year or two beyond that.
Elegant Themes will be providing some kind of converter for old websites and a fallback system for sites to continue using shortcodes for a while (just like how the old backend builder is still available but not recommended for new sites). It won’t be an easy transition but a long, slow process to make sure it doesn’t break anyone’s site as we move to the new system.
5. WooCommerce modules
Since v 3.29 Divi has shipped with 16 WooCommerce modules and now ET are close to finishing development of their WC v2 update. This will introduce more WC modules to allow full control of cart and checkout pages.
The update is just ending round 1 of quality control and about to enter round 2 of perhaps 2 or 3 rounds, depending on how many bugs they find to iron out. It should be with us soon.
6. Improved full site editing
Currently, if you’re editing a page and see something in the header you want to edit, you have to exit the page builder, navigate to the theme builder, work out which theme builder template applies to the page in question then open the header editor. Instead, we’ll soon be able to just jump in and edit the relevant theme builder element right from within any page it appears on.
7. Conditional display
There are a bunch of plugins out there that can provide this feature in Divi but soon this will be built natively into Divi. This will allow people to show or hide content based on conditions like time ranges, whether the user is logged in or not etc. What would make this feature really powerful would be a link between the status of conditional fields and the conditional display of elements. Fingers crossed, we’ll have to wait and see.
8. More icons
We’ll be seeing a lot more icons in the builder and they’ll be presented with a more powerful icon manager, with the ability to filter or search through them. I don’t know how many new icons there will be exactly and I’m sure the collection isn’t set in stone yet, but I wouldn’t be surprised if it’ll be something in the region of 1000 icons.
9. Background masks
Another feature coming soon is the ability to add masks and patterns to backgrounds. This will add another layer to backgrounds and allow all kinds of cool shapes and effects.
10. Multi-stop gradients
If you’ve wished for a multi-stop gradient builder in Divi as long as I have then you’re in luck. I wonder if this feature will allow complex non-linear gradients? Probably just linear, but we’ll see.
11. The end of the lifetime subscription?
Considering the value Divi provides it’s amazing it’s so cheap, especially the lifetime subscription. ET has always prioritised cultivating a strong community over making money and that’s one thing that makes Divi so popular. However, the lifetime subscription won’t be around forever. They’ll continue to focus on investing in the developer community and the ecosystem around Divi rather than changing the pricing model, but it’s likely the lifetime license will be removed at some point in the future once ET has something else to make up for it.
As for what that extra new feature could entail, Nick offered a few ideas of the kind of services agencies would find helpful, like tools to help agencies manage multiple Divi websites and team collaboration tools.
When will Divi be getting rid of the Google+ icon?
This final point is just to highlight how focused ET are on developing new features. Divi’s GitHub repo has about 3,000 bugs and feature requests and ET has to work out how to prioritise them all. In response to this question Nick asked whether we should focus on fixing problems that will be irrelevant soon? For instance, they don’t want to focus on improving the default header and footer much longer because that’s becoming less important as people are building great headers and footers with the theme builder. So yes, in due course the Google+ icon will disappear, but don’t hold your breath for it.