Gutenberg vs Elementor, Divi or Visual Composer

Yes, I admit, the title of the entry is a bit clickbait. In this post you won’t find any measurements in which I show you that Gutenberg is the best or why you shouldn’t use another visual builder. In fact, in a way, I’m going to recommend to some readers the use of other visual builders for WordPress.

What I use

If I have to make a website from scratch or completely redo an existing website and I am given the freedom to use whatever I want, my choice is Gutenberg, always with the GeneratePress theme and its corresponding child theme, plus GP Premium and GenerateBlocks.

But if I am working with a website made with any other visual builder, there is no problem at all and in most cases, I would not recommend switching to Gutenberg.

Do the other visual constructors perform so poorly?

No, quite the contrary, I would say that in most cases, they still beat Gutenberg in many respects.

Although I have put the “big contenders”, in addition to Elementor, Divi or Visual Composer, we also have Oxygen that does a great job with the resulting code, the veteran Beaver Builder, Thrive Architect, the simpler and lighter Site Origin Page Builder and many more like Brizy, Live Composer.

I have made websites completely from scratch with Divi and with very good results, because Divi was what the client knew and knew how to handle it, so it was the most appropriate choice. I have also optimized websites with Visual Composer, achieving very good results.

I will give you a couple of examples without sharing customer urls.

Below you can see the response time for the first byte (TTFB or Time To First Byte) of a web page made with Divi:

Page layout with Divi

Less than 43 milliseconds to process PHP requests for the much-maligned shortcodes generated by Divi.

In this second example we have a page made with WPBakery Page Builder. It is a dual-language WooCommerce, with WPML (which has also been criticized a lot and not always rightly so), many product filters and quite a lot of plugin loading.

WooCommerce with WPBakery Page Builder

The response in less than 230 milliseconds, I think, is a very good result considering all the complexity of the page.

Do I mean by this that both typesetters are faster than Gutenberg? Well, as the good Galician that I am, I will say that it depends, or I will answer with another question: fast in what? If we talk about fast response from the backend, it will depend on how well optimized we have the whole set of web server, database, cache, etc..

If we talk about the speed of the page, it depends on the skill we have with Gutenberg and the additional blocks we have installed or our skill with Divi or the layout we are dealing with. I am absolutely sure that there are implementers who will make a page in half the time that I use, or even less.

But do they generate such a large amount of garbage in the resulting code?

Here I keep hearing many times the same phrase: “Gutenberg generates HTML”, and Elementor generates chocolate with churros, right? And Divi churros … no, Divi saves shortcodes in the database, but at the end Divi is responsible for converting those shortcodes into HTML, because, gentlemen: Browsers interpret HTML, no shortcodes, no Gutenberg comments or anything like that. That part stays in the database and what is dumped to the client is pure HTML (yes, I know, with some CSS, JavaScript, a JSON or other things, but basically HTML).

Another issue is the time it takes to generate such HTML because it can be dumped directly from the database or have to be preprocessed (shortcodes), but several factors come into play here, for example, if we already have it pregenerated in memory in a Redis and the shortcode than the version already saved in HTML, because we have to read from a MySQL slower than the RAM memory.

And no, shortcodes are neither the latest wonder and solution to everything, nor are they the devil. We all talk about the great Contact Form 7 plugin, which as you know… generates shortcodes that is responsible for converting to HTML for the browser to display it to the user.

So what’s the problem with visual constructors?

The most common problem with visual constructors is the amount of HTML elements they generate, a div with an outer div with another inner div, etc., etc., etc.. but this is a problem of the visual builders and sometimes also of Gutenberg, which works with blocks and there… we have everything.

Therefore, the first thing we must do is not to generalize, if for example we see the following div structure:


We can see that to show the third level header (H3) we have a structure of 6 divs that make the DOM (Document Object Model) grow and that will later give us the consequent protest from Google saying that the DOM is too big:

Excessive DOM

Well, for those who are curious, the structure shown above is made with Gutenberg (not one of the “guilty” builders), with the GeneratePress theme. If we had done that work in a “handmade” way, we could have reached the same result with one or two divs and some CSS, but what visual editors (whether Gutenberg or any other) achieve is to give us many options for all kinds of cases and not something specific and adapted only to what we want to show at that moment (custom-made).

But Google complains a lot about the code of my page made with Elementor.

Yes, true, if you want a perfect page in terms of scores, you will have to fine tune the shots a lot or have a big budget, “Google is bringing the web closer to everyone”, but “the web of the one who has money to pay the best developers”.

If we go back to the screenshot in which Google complains about the excessive size of the DOM… well, it’s not from the page made with Gutenberg, but from a page of yours:

And the results are not very good to say the least:

PageSpeed Google Workspace

So what should I do?

Use things wisely and in moderation. I have optimized some pages with Visual Composer that to separate two different sections inserted “separators”, as each separator separated 30 pixels, insert 3 to achieve this separation ….

If instead of doing so, we insert only one separator and in the separator properties we change the margin from 30 to 90… we save several divs that are inserted with each separator. But if we do it right and instead, in the top section we give it a bottom margin of 90 pixels… we save all the separators, less DOM elements, faster loading and less complexity in the design.

Visual Composer margin

But here we come to one of the crux of the question, the correct use of the tool, because this example that I have just told you about the separators, I have seen the same in designs made with Gutenberg, or columns with blocks inside that included other blocks and… the problem is in how it is designed visually rather than whether it is with Gutenberg, Divi or the layout tool you want.

And it is not always wrong, sometimes the design requires certain“tweaks” to be made that are not the most appropriate, but instead work to achieve the expected design.

And the typesetters do not present any more problems?

Yes, another of the big problems they present is that they bring the creation of websites to more people… the same as with WordPress that give the possibility of having a website to a wider range of people; the same happens with the visual layout designers.

We may rave about Visual Composer, but it has done more to bring WordPress to a wider audience than any other software has ever done.

99% of the people I’ve heard railing against Divi, Elementor or Visual Composer, are fellow professionals, i.e. programmers. I myself, a few years ago at the beginning of getting in touch with the WordPress community, had a speech against implementers… I wish today I had a good implementer and I would dedicate myself to programming other parts of the backend.

If at some point I had a haughty attitude about implementers, which I admit I did, today it is clear to me that each task needs its own professional, be it an accessibility expert, a frontend, designer, layout designer, implementer, copywriter, SEO, SEM, server expert… one can do a bit of everything, but as I said before, a good implementer will make a page with Gutenberg, Divi, Elementor or whatever, two or three times faster than me and with a visual result more successful than mine.

That said, I think that the big problem of the layout designers is us, the programmers, because they don’t do things as well as we do, they produce a worse code than we do and they are going to take our work… well, I think that by now we should all know that there is enough work for each of us, and there is a need for developers who make pages at an affordable price with a Divi and clients who need a fully customized website. Burger King burgers and Michelin-starred gourmet burgers are needed.

I think it is very valid to say “I don’t work with Divi or Elementor, only custom websites.“Of course, everyone should be in their own niche, with their prices and their way of working, but what we should not do is to belittle those who do use Divi or the visual editor of the moment, and, if not we will remember the other devs that programmed for real and they look down their noses at us because we don’t program, we do it with WordPress or going one step further, because we program in PHP and we don’t use a real language (for example Python).

So do I use Gutenberg or not?

Well, I shouldn’t be the one to tell you if you should use one or the other, but since you are on my website and even if you didn’t ask for my advice, I’m going to give it to you, because that’s why it’s my website.

If you’re just starting out, use Gutenberg, hands down. If you are using another layout tool, I would try Gutenberg in some new page, tests, some landing page… but the truth is that although Gutenberg allows us to do almost everything, sometimes we must complement it with some CSS and even if it’s just one line… you have to know CSS. If you have experienced moving an element in Gutenberg to a certain position or selecting several elements, you will know that other editors still beat it. And the more options Gutenberg has, the more code it must insert to adapt to all these possible circumstances.

Gutenberg is not the future, it’s the present, but that doesn’t mean we should ignore everything else. Just because WooCommerce is one of the best e-commerce plugins for WordPress, does not mean that it is the best, the only one or the most suitable in certain occasions.

Let’s be understanding, let’s keep in mind that there are many types of customers, many situations that require different measures and let’s not get into the attitude of looking down on those other developers who use different tools than ours or those that we believe to be the most appropriate.

As I said from the beginning, I use Gutenberg whenever I can and I think with good results in terms of performance; although I said I was not going to make time comparisons, compare me a little bit with Google sometimes helps to boost morale and seeing the results of your Google Workspace page, which is still a landing page (we are not talking about Gmail and all its functionality), I can boast a little bit of results.

Yes, I know it’s wrong to brag, but I’m tired of clients telling me that Google tells them that their page DOESN’T EXCEED their evaluation… IF ITS OWN PAGES DO NOT EXCEED IT.

But do not trust these measurements or any other that you see out there, it all depends on the functionality offered by the page, if it really converts… so many factors, that the measurements are just that, measurements and they are worth for what I just did, to show off, even if it does not contribute anything else.

If you want a fast page that always gives 100% for Google, listen to the great master of WordPress, Fernando Tellado:

YouTube video

Join my superlist ;)

I won't share your details with anyone or bombard you with emails, only when I publish a new post or when I have something interesting to share with you.

Leave a Comment