Divi vs Elementor: Performance comparison

With the latest release of Divi 5, we think it is a good idea to finally put two of the most popular page builders in WordPress head to head. Even though, in general, we do not recommend using either of them, it’s always interesting to see which one gets closer to staying true to its claims.

In this post we compare a page built with Divi with a page built using Elementor. Since Divi also acts as a theme, when testing Elementor we will use their official theme, Hello Elementor. These are the versions used for the test:

Divi: v5.0.1
Elementor: v3.35.7
Elementor Pro: v3.35.1
WordPress: v6.9.1
Hello Elementor: v3.4.6

Test conditions

We used a Hetzner CX22 server with 2 vCPUs and 4 GB of RAM. Nothing fancy, but enough for our tests. All tests were performed under identical conditions:

Hello Elementor theme running when testing a page built with Elementor (Divi is itself a theme).
Elementor Pro running when testing a page built with Elementor.
Divi 5 freshly installed, not upgraded from Divi 4.
Both Divi and Elementor running with default settings.
No other plugins installed, except Code Profiler Pro to measure performance.
No caching systems.
We created one sample page with each builder, using only native Elementor widgets in Elementor and native Divi modules in Divi, with the following content:
- A full-width hero section with a background image, text, and a button.
- A simple gallery of 5 images. We configured Elementor to load the Medium thumbnail size. Divi does not allow changing the thumbnail size. Instead, it creates many additional thumbnail sizes and decides which one to load dynamically.
- A couple of buttons.
- 2 columns with two strings of text.
- A loop displaying a list of posts, which contains only four posts.

Here’s how the page looks with Elementor and Hello Elementor:

And here’s how the page looks with Divi:

Performance metrics

We measured each builder’s performance using the following metrics:

Total PHP execution time (ms) of plugins and theme while visiting the generated pages on the frontend.
Total PHP execution time (ms) of plugins and theme while loading the WordPress admin dashboard.
Time To First Byte (TTFB) and Load event (ms) in the editor and on the frontend pages. We measure Load instead of DOMContentLoaded because especially editors are JavaScript driven applications whose interface and functionality initialize only after their scripts and other resources have fully loaded and executed, which is when the Load event fires. TTFB and Load were automatically calculated using the browser developer tools together with a custom snippet that reloads the same page 10 times and calculates the average.
Total CSS and JS size and file count (KB) for frontend pages. For CSS we also count the size of inline CSS, which is as important for performance as CSS delivered in separate files.
Total CSS and JS size and file count (KB) for the editor.
Size of the HTML (KB) generated in the frontend.
Lighthouse results, emulating a Moto G Power device with Slow 4G and a 4x CPU throttle, the same profile used by PageSpeed Insights.

Execution times were measured with the Code Profiler Pro plugin. Each test was run five times, and we averaged the results to make sure we got accurate times.

Results

PHP execution time (ms)

Context	Divi	Elementor
Dashboard	0.200	0.453
Frontend page	1.087	0.814

Result: In absolute numbers, both page builders are more or less equal in terms of execution time. While Divi performs better in the backend, Elementor performs better in the frontend. However, in relative terms, it’s worth noting that Elementor is twice as slow as Divi when browsing the backend. Since we are checking the Dashboard page, it is possible that the timings are affected by the Elementor Overview widget that the plugin forces you to have (and that you can remove with a little hack).

Frontend TTFB and fully loaded time (ms)

Context	Divi	Elementor
TTFB	904	804
Load	1405	1403

Result: Both builders are practically equal in terms of TTFB and fully loaded time. It’s almost funny that we managed to get nearly identical times with the the Load event, which represents the time spent to load all immediate dependent resources of the editor (that is, files explicitly referenced by the HTML document itself, not resources that are loaded later by scripts).

In general, compared with Gutenberg, Divi and Elementor do provide many more modules and customization options, but that comes with a cost that does not disappear when viewing the page on the frontend.

Editor TTFB and fully loaded time (ms)

Context	Divi	Elementor
TTFB	856	977
Load	4692	4660

Result: Again, both builders are practically equal, with Elementor producing a slightly higher TTFB.

CSS and JS file requests

Context	Divi	Elementor
Frontend CSS	0 requests (129 KB inline, 115 KB from Divi alone)	4 requests, 75 KB transferred (13 KB inline, 1 KB from Elementor alone)
Editor CSS	44 requests from Divi alone (3548 KB transferred)	179 requests from Elementor alone (1191 KB transferred)
Frontend JS	14 requests (227 KB transferred)	10 requests (182 KB transferred)
Editor JS	138 requests from Divi alone (20136 KB transferred)	96 requests from Elementor alone (7279 KB transferred)

Result: Divi appears to lose this battle, for several reasons.

Divi appears to inline all CSS on the frontend, which is actually counterproductive for performance. By inlining CSS, Divi prevents the browser from caching it for future visits or other pages within the same session. This also increases the HTML size; inlining some CSS can be good, but inlining everything is not. Having 115 KB of CSS inline is too much to justify this approach.
Divi always makes more requests and ends up with the largest JS/CSS size. That’s bad for the user because the page may have a higher chance of taking longer to load (more size and requests), and it’s bad for the browser because it needs to do more work to process all the extra CSS and JavaScript.
The editor is where Divi’s weight becomes especially clear, even after a major new release. More than 20 MB of JavaScript files are loaded, compared with less than 8 MB for Elementor. Those 20 MB include, unfortunately, files of questionable usefulness such as a 2 MB file named et-ai-app.bundle.js (AI everywhere…). But that’s not a problem exclusive to Divi; Elementor loads a combined size of 1.5 MB spread across three files only for AI ~~bloat~~ features.

HTML size

Divi	Elementor
161 KB	45.5 KB

Result: First of all, it should be noted that the server was not using any compression method such as Brotli, Zstandard, or Gzip. On a well optimized site these sizes would be smaller because the HTTP compression would be active, but this test still highlights the effect of inlining all CSS, which significantly increases the size of the HTML document.

Lighthouse

Divi

Elementor

Result: Honestly, neither builder is an option we would recommend if your goal is to pass the Core Web Vitals or get a good score on Lighthouse. In general, it seems as if Elementor is worse optimized than Divi because it has more unused JavaScript and CSS. However, Divi increases almost all Lighthouse metrics, especially the CLS. This was already a concern in previous versions, and it still appears to be a problem here. That’s most likely why it gets a worse score too.

Key takeaways

Sadly, we cannot say many positive things about Divi, even after the major redevelopment they did for version 5.

The editor is more responsive than the previous version of Divi. Not only that, in our opinion it is also more user-friendly than Elementor.
Divi generates significantly heavier pages than Elementor and uses bad performance practices, such as inlining too much CSS.
In general, every measured aspect of Divi is slower than Elementor, except for a couple of non-critical ones.
All Core Web Vitals take a hit when using either builder, especially the CLS when using Divi, which continues to be a persistent issue in Divi 5.

Conclusion

After spending time with the new version of Divi, we must admit that the editor feels much more responsive than before. In version 4, the editor felt clunky, and on underpowered servers it could take an eternity to load. That problem appears to have been addressed, and compared with Elementor, which is very unfriendly to users, it’s a breath of fresh air.

However, it seems that only the perceived responsiveness of the editor has improved. Divi’s performance remains a problem, particularly the CLS, which at this point seems almost like its trademark.

So yes, Elementor is better than Divi in terms of performance. But wait! That doesn’t mean that you should use Elementor instead. There are many more page builders out there, and both Elementor and Divi are among the worst compared with the others, especially when you start adding even more bloated add-ons to them. If you would like our recommendation, stick to Gutenberg. Here is how you can rebuild your site without using a page builder.

So, are Elementor or Divi “fast and lean” as they claim? Unfortunately, they are not.