Divi 5 is already out. Are you excited? Let’s see if there’s a reason to be, because previous versions of Divi were known to be slow and bloated. Maybe Elegant Themes have solved this. After all, they claim it’s fast and lean…
In this post we compare a page built with Divi with a page built using the native WordPress block editor, Gutenberg. Since Divi also acts as a theme, we will use the WordPress default theme (Twenty Twenty-Five) when testing Gutenberg. These are the versions used for the test:
- Divi: v5.0.1
- WordPress: v6.9.1
- Twenty Twenty-Five: v1.4
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:
- Twenty Twenty-Five theme running when testing a page built with Gutenberg (Divi is itself a theme).
- Divi 5 freshly installed, not upgraded from Divi 4.
- Both Divi and Gutenberg running with default settings (Gutenberg does not technically have configuration settings, but we did not change its default behavior).
- 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 WordPress blocks in Gutenberg 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 Gutenberg 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 Twenty Twenty-Five and Gutenberg:
And here’s how the page looks with Divi:
Performance metrics
We measured each builder’s performance using the following metrics:
- PHP execution time (ms) of the generated pages on the frontend. Since Gutenberg is integrated with WordPress, we have no easy way to distinguish what part of the total execution time belongs only to Gutenberg. Therefore, we measured the total execution time of all plugins and the active theme.
- PHP execution time (ms) of the WordPress admin dashboard (with the same caveat as above).
- Time To First Byte (TTFB) and
Loadevent (ms) in the editor and on the frontend pages. We measureLoadinstead ofDOMContentLoadedbecause 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 theLoadevent fires. TTFB andLoadwere 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 | Gutenberg |
|---|---|---|
| Dashboard | 0.200 | 0.012 |
| Frontend page | 1.087 | 0.045 |
Result: The dramatic difference is obvious. When we added Divi, we added roughly one full second to the execution time, which directly affects page load time as well.
One could argue that because we cannot isolate Gutenberg when measuring execution time, the time measured when using Divi also includes Gutenberg’s. But that is precisely the point. To use another page builder like Divi, it must be installed “on top” of the existing builder (Gutenberg), which inevitably affects loading times. The question we wanted to answer here is how much.
Frontend TTFB and fully loaded time (ms)
| Context | Divi | Gutenberg |
|---|---|---|
| TTFB | 904 | 485 |
| Load | 1405 | 938 |
Result: The TTFB is almost double when using Divi. The Load event is about 50% slower with Divi than with Gutenberg, 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).
Divi does 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 | Gutenberg |
|---|---|---|
| TTFB | 856 | 711 |
| Load | 4692 | 1488 |
Result: The TTFB is quite similar between the two editors, although still noticeably better with Gutenberg. However, the Load event tells a very different story. With Divi, the browser takes more than three times longer to fully load the editor interface.
CSS and JS file requests
| Context | Divi | Gutenberg |
|---|---|---|
| Frontend CSS | 0 requests (129 KB inline, 115 KB from Divi alone) | 2 requests, 36 KB transferred (62 KB inline total) |
| Editor CSS | 44 requests from Divi alone (3548 KB transferred) | 8 requests total (1359 KB transferred) |
| Frontend JS | 14 requests (227 KB transferred) | 3 requests (68 KB transferred) |
| Editor JS | 138 requests from Divi alone (20136 KB transferred) | 93 requests total (6465 KB transferred) |
Result: 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.
When it comes to JavaScript, the inline code is negligible in both cases, but the number of requests is significantly higher with Divi.
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 7 MB for Gutenberg. Those 20 MB include, unfortunately, files of questionable usefulness such as a 2 MB file named et-ai-app.bundle.js (AI everywhere…).
HTML size
| Divi | Gutenberg |
|---|---|
| 161 KB | 96 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
Gutenberg
Result: 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. It is also concerning that Divi introduces a lot of unused JavaScript, which Lighthouse flags during the synthetic performance test.
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 to use. However, it’s slower to load.
- Divi produces much heavier pages than Gutenberg, with bad practices in performance (unused JavaScript and inlining too much CSS for example). Divi generates significantly heavier pages than Gutenberg and uses bad performance practices, such as leaving unused JavaScript inlining too much CSS.
- In general, every measured aspect of Divi is slower than Gutenberg.
- All Core Web Vitals take a hit when using Divi, especially the CLS, 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 a very long time to load. That problem appears to have been addressed.
However, it seems that only the perceived responsiveness of the editor has improved. Performance remains a problem, particularly the CLS, which at this point seems almost like a trademark of Divi.
Yes, Divi offers many features, but we believe the performance cost is difficult to justify. Gutenberg is already a viable option for most users, is better integrated with WordPress because it’s part of it, is easier to use, and generates significantly faster pages.
So, is it “fast and lean” as they claim? Unfortunately, it’s still not.
