For most of the last decade, the honest answer to “should we build this in Divi?” depended on how much the site actually needed to do. Divi 4 was a comfortable place to design. It was also built on shortcodes, which meant every module you dropped on a page got wrapped in a string of bracketed code that WordPress had to parse and expand on every request before it could render anything. For a five-page brochure site, that was fine. For a site running hundreds of pages, custom functionality, and real traffic, the architecture had a ceiling, and we ran into it more than once.
Divi 5 removed that ceiling. The version that shipped at the end of February isn’t a feature update. It’s a ground-up rewrite of the builder’s core, and the part that matters most for the businesses we work with isn’t a new design control. It’s that Divi quietly stopped being only a front-end design tool and started behaving like something we can build on.
What was actually wrong with the old foundation
Shortcodes were never the right way to store the structure of a complex website. They worked, the way a lot of things in WordPress work, until they didn’t. Every module’s settings lived inside text strings that had to be unpacked at render time. The more you added, the more there was to process, and the front-end output carried a layer of weight that had nothing to do with what your visitors actually saw. This is the source of the “Divi is bloated” reputation that followed the theme around for years. It wasn’t unfair.
The other problem was extensibility. If you wanted Divi to do something it didn’t do out of the box, your options were limited and fragile. Custom modules meant working around the shortcode system rather than with it. We could do it, and we did, but it was the kind of work where you spent as much time defending against the architecture as building on top of it. That’s a bad place to be when a client is paying for a result, not for your patience.
The rewrite changed what kind of tool Divi is
Divi 5 throws out shortcodes entirely. Content is now stored in a block-based format aligned with how WordPress itself stores content, and the builder runs on a modern React-based framework instead of the old PHP-and-shortcode stack. Elegant Themes describes this as shedding a decade of technical debt, which is marketing language for something that’s genuinely true: the thing underneath is different now.
The performance follows directly from that. Divi 5 loads JavaScript on demand, pulling in only the libraries a given page needs rather than shipping everything to every visitor. It generates critical CSS automatically, so the styles needed for above-the-fold content load first. Independent testing has shown the new architecture cutting page load times roughly in half and reducing the number of HTTP requests substantially compared to Divi 4. Those aren’t cosmetic gains. They’re the difference between a site that passes Core Web Vitals and one that quietly costs you rankings and conversions.
But speed is the headline, not the story. The story is the new Divi API.
The API is the part that matters
Divi 5 ships with a developer API designed for building custom modules and integrations natively, as first-class parts of the builder rather than workarounds bolted onto it. That’s a meaningful shift. It means a custom module we build behaves like a native one: it’s fast, it respects the design system, it survives updates, and it doesn’t fight the platform. For a business that needs its website to do something specific and unusual, that’s the whole game.
This is what we mean when we say Divi became a development platform. A page builder lets you arrange existing pieces. A platform lets you build new pieces that belong. The Loop Builder and Query Builder are a good example of where this leads. They let you pull live, structured content from your site’s database and display it however you want, and they work directly with Advanced Custom Fields, including repeater fields. If you’ve ever needed a website to behave like an application that happens to live on WordPress, that capability used to require custom development that sat awkwardly alongside the builder. Now it’s part of the builder.
The layout engine moved to CSS Flexbox and CSS Grid with seven customizable breakpoints, which sounds like a designer feature and is also a developer one. It means the structures we build translate cleanly to standard CSS rather than to Divi’s old internal layout logic, so the output is more predictable and easier to extend. Less translation, fewer surprises, less of a website’s budget spent on overhead nobody can see.
Why this changes who should be building in Divi
For years, the assumption was that Divi belonged to one end of the market and serious development belonged to the other. You picked Divi for speed of design or you picked a hand-built theme for control, and you accepted the tradeoff. Divi 5 closes most of that gap. You can now have the visual building speed and the clean, performant, extensible foundation at the same time, which is exactly the combination most growing businesses actually need and rarely get offered.
The catch is that the new architecture rewards being built into properly and punishes being treated like the old one. Divi 5 includes a backward-compatibility layer so existing Divi 4 sites keep running after you upgrade. That’s genuinely useful, and it’s why migration doesn’t have to be a crisis. But legacy Divi 4 modules run in a compatibility mode that doesn’t get the new performance benefits. A site that’s been “upgraded” by clicking the button and walking away is technically on Divi 5 while still carrying most of Divi 4’s weight. Getting the actual gains means rebuilding on the native architecture, and knowing which parts to rebuild first.
The Divi 4 question most businesses are getting wrong
Elegant Themes committed to supporting Divi 4 for at least six months past the Divi 5 launch, which buys everyone some breathing room. That support window has led a lot of site owners to one of two conclusions, and both are usually wrong. The first is to migrate immediately because the new version is out. The second is to do nothing because nothing is broken yet. The right answer almost always sits between those, and it depends on details specific to your site.
The variables that matter are how much custom functionality your site has, how heavily it leans on third-party plugins, and whether those plugins have shipped native Divi 5 versions yet. A site built mostly with stock Divi modules and a couple of well-maintained plugins is a straightforward migration. A site with custom modules, a half-dozen Divi-dependent plugins, and integrations wired into forms or a CRM needs a plan, because the plugins that haven’t been rebuilt for Divi 5 will run in compatibility mode, and compatibility mode is where the performance gains quietly disappear. Knowing which of your dependencies are ready, and which aren’t, is most of the work of deciding when to move.
There’s also a difference between migrating and rebuilding, and it’s worth being clear-eyed about which one a given site needs. The one-click upgrade preserves your content and keeps the site running, but it doesn’t modernize the underlying structure. For a lot of sites that’s fine as a first step. For the ones where performance is the entire reason you’re moving, the real value comes from rebuilding the high-traffic templates on the native architecture so they actually use the new framework. That’s not a reason to avoid the upgrade. It’s a reason to go in knowing what you’re getting and in what order.
Where Lion Ridge fits
This is the work we do. If you’re starting something new and want it built in Divi 5 from the foundation up, with custom modules and integrations that use the API the way it was meant to be used, that’s a project we’re set up for. If you’re sitting on a Divi 4 site and trying to decide whether to migrate, when, and how to do it without breaking what’s working, that’s a conversation worth having before you touch the upgrade button.
We’ve been building and maintaining WordPress sites since 2014, through every version of Divi along the way, including the sites we run for organizations with real traffic and real consequences when something goes down. We know where the old architecture’s limits were because we hit them, and we know what the new one makes possible because we’re already building on it. Migration in particular is the kind of thing that looks simple in a demo and gets complicated in production, especially when third-party plugins and custom functionality are involved. Doing it on a staging environment, in the right order, with someone who understands what’s actually changing underneath, is the difference between an upgrade and a recovery.
If you’re developing in Divi or thinking about moving to Divi 5, that’s squarely what we’re here for. Get in touch and tell us what you’re working with, and we’ll tell you honestly what the move involves.
