Does The Divi Static CSS Update Deliver?

Last week, Elegant Themes (ET) released an update for their popular Divi theme and Divi builder plugin that introduced a significant new feature; static CSS file generation. They claim that going away from inline CSS and generating a static CSS file will improve page load times and reduce the size of your pages. Let’s put it to the test!

Back in April 2016, we published the WordPress Framework Showdown where we reviewed and compared the four frameworks that received the most votes in our Best WordPress Framework poll. The Divi Builder plugin got high marks for functionality but produced middle-of-the-pack scores in our performance testing, showing there was room for improvement. Since we use Divi on the Barrel Roll website, we decided to use our live site as a test bed. Dangerous? Yes! Brave? Even more yes!

Testing Divi’s Static CSS Files -Test #1: Homepage

We started with a complete backup of the site and proceeded to run a series of tests with GTMetrix and Pingdom with our site running Divi 3.0.51, the version just before the static CSS update. These two tools measure things a little differently, and using both gives us a better understanding of what’s going on. We ran three tests with GTMetrix and one with Pingdom. Then we updated to Divi 3.0.60, ensured static CSS was enabled, cleared and preloaded our WP Rocket caches, tested in Chrome incognito to generate full cache files, and re-ran the tests.

The results were interesting. While the new version of Divi did improve page load times on average, the best performance numbers were almost always from the tests running on Divi 3.0.51. Rather than creating a single static CSS file, as mentioned in the blog post, Divi created a dozen new CSS files.

You can view the complete Pingdom results here for Divi 3.0.51 and here for Divi 3.0.60. There you can see all of the additional CSS files that were generated.

Here are the results from GTMetrix, with the best numbers in bold. The first three rows are running Divi 3.0.51, and the last are running Divi 3.0.60 with static CSS enabled.

Date	YSlow Grade (%)	PageSpeed Grade (%)	Onload Time (s)	Total Size (bytes)	Total Requests	TTFB (s)
7/4/2017 14:25	66	82	1.402	1407122	71	252
7/4/2017 14:26	64	83	1.12	1402518	73	237
7/4/2017 14:26	64	83	2.137	1402386	71	238
7/4/2017 14:32	63	82	1.231	1415815	84	236
7/4/2017 14:32	64	82	1.409	1415743	83	260
7/4/2017 14:33	63	82	1.689	1415866	83	267

Across six runs in GTMetrix, the average onload time for Divi 3.0.51 was 1.553s while Divi 3.0.60 was 1.443. The average total size was 1.404MB compared to 1.415MB. In Pingdom the results were a little different, which the previous version loading in 1.26s while the new version loaded in 1.4s.

Testing Divi’s Static CSS Files -Test #2: Simple Test Page

Those results seemed pretty inconclusive, so we simplified things. Our homepage is heavy with graphics and scripts, so we created a simple test page using the Divi builder and a single text module.

Here are the results from GTMetrix, with the best numbers in bold. All of these tests were done with Divi 3.0.60. The first three results are with static files enabled, the last three with the setting disabled.

Date	YSlow Grade (%)	PageSpeed Grade (%)	Onload Time (s)	Total Size (bytes)	Total Requests	TTFB (s)
7/4/2017 16:13	63	87	1.209	828324	61	199
7/4/2017 16:14	68	87	1.101	827718	62	221
7/4/2017 16:15	63	86	1.762	828446	62	209
7/4/2017 16:17	63	87	0.957	827594	60	203
7/4/2017 16:17	66	87	1.137	827086	61	197
7/4/2017 16:19	68	87	1.783	827001	60	215

Once again, Divi performed better when static files were disabled, though average speeds still improved slightly when enabled – average onload times were 1.36s vs 1.29s. Here are the Pingdom results with static files enabled and disabled.

Conclusions

Although average page load times do appear to improve slightly with static CSS files enabled in Divi, a deeper dive into the data shows that all that glitters isn’t, in fact, gold. The best load times were always when static CSS was disabled or not present at all, as were the lowest total size, total requests (which makes sense), and TTFB.

The TTFB (time to first byte) results are telling. That figure can be an indicator of server load, and since one of the stated benefits of the update is to reduce server load, we can see that this wasn’t accomplished. Relying on TTFB to measure server performance is far from perfect, but it does indicate that we’re not seeing significant performance gains from the static CSS files thus far.

Since ET released the update on June 28th, a flurry of fixes has been released to resolve various bugs and compatibility issues. This has become too commonplace and we’d love to see software tested more thoroughly before being released. We now wait a bit before applying any major Divi update to our member sites to avoid breaking them and having to restore from backups.

Divi’s CEO Nick Roach stated that they tested static CSS for three weeks before releasing it. That wasn’t enough time, but they get credit for being very active in their forums providing support for their users and for pushing out a quick series of updates that have, in our testing, resolved a number of issues.

So, should you update to the latest version of Divi?

Yes. The bug fixes they incorporate make that a no-brainer. Should you enable static CSS generation? That’s a little harder to answer. If you have a solid caching solution in place, you may be able to tweak it and see some benefits from the static CSS files. If you don’t or don’t even know what that means, then you should wait for a little more polish before clicking Enable.