After two years of development, Gutenberg (and its delivery device, WordPress 5.0) are nearly upon us and people are not happy about it. 900+ one star reviews are a clear indication that it’s not exactly beloved by the community, but those are primarily focused on its lack of polish in the user interface, missing functionality, and poor documentation.
We’ve been wondering; how does Gutenberg fare in the performance department?
Back in August, we conducted a poll asking folks what their favorite WordPress page builder plugin was. We’ve compared some of the most popular plugins with Gutenberg and the Classic Editor to see how their performance stacks up.
What We Tested
In thinking about the best way to setup this test, we tried to come up with the most likely use-case scenarios for a typical WordPress user who might use a page builder rather than letting the theme handle design. We kept it simple, choosing a large featured image, four smaller featured images, and some text blocks. This was a design we could easily (well, except in Gutenberg) replicate and should be a good example of how a typical post or page might work.
We started with a baseline test using the current version of WordPress, 4.9.8 with the 2017 default theme active. This was bloated a bit by the 112kb default header image, so we installed the 2019 default theme that’s included with WordPress 5.0 RC1 and ran numbers on that for comparison.
With onload times in the mid-300ms ranges, it’s safe to say that what we’re all used to is still performing just fine. The 2019 theme is a bit lighter than 2017, even if you remove the 112kb header image, so it’s pretty impressive that 2017 loads a hair faster. This could point to the 2019 theme being in need of a bit more fine-tuning, especially given how sparse it is by default.
WordPress 5.0 with Beaver Builder
Of all the third-party page builders, Beaver Builder was easily the lightest at 250kb. This didn’t translate into an equivalent advantage in speed, however. Beaver Builder managed to edge out Brizy by less than 100ms but beat Divi by a healthier margin of 267ms.
Building the page in Beaver Builder was easier than Gutenberg and Brizy, but not as intuitive as Divi. There is a lot more clicking involved to do basic things like adding an image in a blank column and most of that requires moving your cursor to the top-right corner of the page and clicking the plus button. It’s wasted movement, but it’s something you’d get used to after a while. Another bizarre choice is how much padding and margin Beaver Builder adds. Everywhere you look, BB is adding 20px around your elements without asking. You can change it in Global Settings, but it’s kind of odd to see a page builder make a design choice like that right out of the gate.
WordPress 5.0 with Brizy
Coming in at the heaviest page size (discounting the 2017 default theme’s 112KB header image), was Brizy. At 351kb, you’re adding over 100kb to your page weight over stock WordPress. Performance didn’t take a massive hit compared to the other third-party page builders, as Brizy finished in the middle of the pack with a 1.091s onload time.
Compared to everything else we tested, Brizy had absolutely no respect for the theme. It overrode footer and widget placements, generating a blank slate for itself to work with, and overrode fonts and other styles without asking. That’s fine if you want the page to be unique, but not great if you have universal elements you’re controlling within stock WordPress. In order to have as close to an apples-to-apples comparison as possible, we added the meta content and footer to the page within Brizy.
Adding a new “Block” in Brizy – a row to you and me – is a bit odd in that they default to two columns instead of one. We didn’t see a way to change this, so be prepared to spend a lot of time deleting columns. You can also add rows from the “Add Elements” menu, but as is the case with some other builders, you can’t scroll well when you have an object selected for drag and drop. Placing elements can be tricky because the snap points are so thin and difficult to target.
WordPress 5.0 with Divi Builder
Although Divi easily has the most plentiful and advanced features of all of the builders we tested, it was also one of the heaviest and came in last in page load speed at 1.267s – nearly double that of WordPress 5.0 with Gutenberg. Considering the built-in minification, combination, and static CSS generation features, it’s a pretty disappointing result.
The builder interface, however, is second to none. It’s intuitive, well designed, and makes building a page faster than anything else we’ve used. It now comes with 37 modules and all of them are above-average quality. We did run into a bug where the Divi Builder couldn’t be activated within Gutenberg, but enabling Classic Editor resolved this and we disabled CE during testing to be sure the playing field was level.
All of these great features come at a price, and that’s performance. Despite their best efforts at optimizing, Elegant Themes still comes up far behind the competition. With TTFB over 600ms on average, it’s clear that the server is working harder as well.
WordPress 5.0 with Classic Editor
We’ve been told that WordPress 4.9.8 and WordPress 5 are nearly identical, save the addition of Gutenberg. That checks out with our speed test results as the two are within 0.04s of each other, with WordPress 5 having the slight edge. It’s close enough to call it a draw.
The difference in page weight is a bit baffling, however. WordPress 5 comes in 35kb heavier. Here’s a comparison.
The Classic Editor includes two minified CSS files which equal about 4kb but it also used a different version of our hero image which was, for some bizarre reason, was 30kb larger than the full-sized version we uploaded.
As far as we know, all the Classic Editor plugin does is re-enable the still-present TinyMCE editor interface and hide Gutenberg. Why does it need two additional CSS files to do this, and what is it using a different version of the image? We’ll ask the developers and let you know what we find out.
WordPress 5.0 with Gutenberg
With the lowest TTFB, the best onload time, and the best fully loaded time, Gutenberg won every speed test. It was also 19kb lighter than anything else we tested, but that’s where the good news ends.
Gutenberg as a page builder is an absolute mess. It took us three times longer to build the test page in Gutenberg than in any other editor, and that includes the Classic Editor where we had to hardcode the columns. It’s buggy and has a user interface that was designed without actual users in mind. It tries so hard to “get out of the way” that you can’t find anything, so you end up clicking around endlessly trying to figure out how to do basic things like add an image to a column. You can’t even add more than two columns in the main interface; you have to use the sidebar. Half the time, when we added an image to a column, it appeared in a new image block underneath the row of columns. Gutenberg kept adding empty columns under images and when we tried to remove them, the entire block of columns broke. We had to re-create the entire page several times to get it right.
There is a nifty “Document Outline” feature that completely missed several blocks and showed others in a confusing manner. It counted 24 blocks when we could see no more than 16. When you use Block Navigation you can’t always get out of it and half of the interface goes white. The mobile interface is a nightmare, with a modal that has to be dismissed before you can even see the title editor and a prompt that tells you to “Start writing or type / to choose a block” even though you can’t start writing because your keyboard isn’t active until you touch the block.
We could go on, but we think it’s pretty clear to everyone that Gutenberg isn’t ready for prime time. Let’s check out the numbers!
WordPress Page Builder Size Comparison
We compared the current version of WordPress, 4.9.8, using the default 2017 theme and the new 2019 theme to WordPress 5.0 RC1 (Current as of 11/23/18) using various configurations.
WordPress 4.9.8 was tested on a single installation since we simply created a test page and switched the themes, but all of the other WordPress 5.0 installations were installed independently so there would be no excess files during testing. Everything was installed on the same server and configured with largely default options; we switched permalinks to Post name and deleted the sample post and page on each installation. We used the latest ZIP from WordPress.org to
WordPress 5 RC is close enough to final that we feel it’s safe to assume these results will hold up to the final release. Here are the versions of the plugins we tested: Divi – 2.17.6; Beaver Builder – 184.108.40.206; Classic Editor – 0.5; and Brizy – 1.0.47.
We went into the testing process thinking Gutenberg would come out fourth at best, behind the third-party page builders, but we were wrong. Gutenberg handed everyone their lunch (and a few their breakfast and dinner, too!).
So, if you want the fastest website WordPress can offer then you need to use Gutenberg, right? Not necessarily. Our test page was limited to a few images and some text, which is effectively best-case scenario for a page builder. Adding additional modules or functionality could cause performance to change dramatically, but we settled on a single, easy to reproduce layout so we could compare each plugin fairly.
The Experience Matters
Gutenberg, in its current state, is not a good page builder. It’s buggy, poorly documented, and the user interface is a mess. You may see better page load speeds, but you’re going to spend a lot more time building those pages and you’re going to have to go back and fix them every time Gutenberg is updated and breaks something.
We can see what Automattic is attempting with Gutenberg, and it’s probably the right direction to go in
In the coming months and years, Gutenberg will simply become “the editor” and will expand to encompass settings for themes and make some plugins redundant. We just hope that someone takes a hard look at the user experience and interface. It needs a complete redesign before it’s going to be a market leader.
Caching Changes Everything
When you look at our results, bear in mind that caching isn’t enabled (except for whatever Divi is attempting to do that clearly isn’t enough). If you install and configure a decent caching plugin, you’re going to see better results. We often see page speeds cut in half with Divi when we configure caching, making it competitive in performance. We’d expect all of the load times seen here to dip below one second if caching was configured, meaning that none of the solutions would be bad, just slower than some of the others.