There is no such way as the perfect PageBuilder
If you ask two WordPress agencies, you will get at least three opinions on which PageBuilder is the best. But many WordPress agencies still prefer Elementor over the WordPress Block Editor (Gutenberg).
Find out here why Elementor is still popular with many WordPress agencies, what advantages and disadvantages the systems have and an outlook on the future.
Stability
Snapshots and the future
The WordPress Block Editor (Gutenberg) was still very shaky in operation with the release of WordPress version 5.0 in December 2018. Important basic functions were missing and are still missing – but can now be easily supplemented by plugins, especially by Bleeding Edge functions, which are provided by the official Gutenberg plugin.
Three years later, the operation has become a lot more stable, but there are always minor operating problems – if you want the most stable experience possible, do not use the Gutenberg plugin – if you always want to use the latest functions, you have to live with slight instabilities.
Elementor works similarly here and is extremely stable by default – but also offers experimental functions that can be activated optionally. Overall, Gutenberg is now as stable as Elementor, so both systems are the same.
So if an agency still has a very bad opinion about Gutenberg, an old stand may have been tried out – after all, Elementor already had two years more time at that time to sufficiently stabilize the software through user feedback.
For the future, Gutenberg will tend to have greater stability than Elementor ever could: By developing the WordPress block editor by the company behind WordPress, you can easily create new standards to provide the most stable experience possible.
Development
Extensibility and learning curve
Elementor makes only small specifications and otherwise relies largely on general WordPress standards when functionalities are to be added by plugins. Basically, there is not much to consider and the learning curve is very flat.
Gutenberg stands for a paradigm shift: The editor interface is implemented via the Javascript programming language React, so that plugin developers, who in the past rarely needed deep Javascript knowledge and basically never came into contact with React, have to overcome a new hurdle. The training and development process for a Gutenberg block compared to an Elementor widget is much more complex and requires more expertise.
To make matters worse, the developer APIs and methods for Gutenberg continue to change very frequently, bugs are often fixed only with a delay and efficient development paths or best practices are not yet sufficiently known or tested – and also change regularly.
What stops Most of Gutenberg, however, is the documentation that is still missing, incomplete or outdated again and again.
For 2022, we hope that work will be done above all to make Gutenberg Block development just as accessible to new developers as the previous plugin development in WordPress. Some developers also want an intermediate layer in PHP for block creation, as familiarization with React deters many potential developers.
PageSpeed
Fast, faster, modular
Basically, Elementor and Gutenberg are frameworks for page layouts. Frameworks offer a standard that harmonizes work steps and provides stability in the background. If a framework is not thought through, there are few ways to improve it afterwards. So the basic concept is crucial.
With PageSpeed, it is important that functions are as modular as possible and are only loaded in the frontend for the user if they are actually in use on the respective page of a website.
Although Elementor is basically modular due to the use of widgets, it hardly shows its strengths. As Google continues to put pressure on pagespeed ,Elementor attempts individually in experiments Scripts and Loading CSS only on demand – with sometimes considerable success, so sometimes up to 500 kilobytes are saved – but from our point of view it shows above all how little Elementor has been optimized with regard to PageSpeed so far and continues to be. Dependencies have to be laboriously unrapped and capped afterwards, a Sisyphean task.
Gutenberg offers a much better, if not perfect, basis. For example, the standard CSS of the blocks in the frontend are not loaded modularly and on demand, the same with the WooCommerce blocks from the same company – but since each Gutenberg block is basically modular, it would actually be easy for the WordPress developers to change that.
With our SV100 WordPress theme, we patch the modularity or on-demand CSS loading for the standard WordPress blocks, so that a few kilobytes are saved in the output. Through our SV100 Companion Plugin, we do the same for some third-party blocks.
Full Site Editing
Edit everything in the same editor.
This is also referred to as full site editing, i.e. an editor that works not only for the content area, but also for all other areas, such as headers, footers and sidebars.
With Elementor, basically all site areas can be customized – including the header and footer. This is not (yet) possible with Gutenberg, but is currently actively in development and for the sidebars already completed and new standard.
A good full-site editor makes developers a bit unemployed, as a visually pretty website can be created easily and without programming knowledge. Therefore, many WordPress agencies prefer Elementor over Gutenberg: Currently, the implementation of a header and footer according to customer requirements for a Gutenberg-based theme may still require programming knowledge.
However, this also shows that many WordPress agencies are basically not development agencies, but websites click together through (more or less skillful) combination of plugins and pagebuilders – concepts regarding data integrity, performance, GDPR, extensibility and future security are usually sought in vain here.
Lower hurdles in the visual implementation of a website can therefore quickly lead to a much lower overall project quality if WordPress freelancers or agencies no longer consider it necessary to provide development expertise that could continue to be project-critical in less visible places.
Powerful or featurecreep?
How many options make sense?
In Elementor, there are countless options for each element – so that they are sometimes nested several times in each other. User-friendliness suffers from this, but some decisions are also difficult to understand:
For example, it is unclear why you should ever be able to select system fonts, since it cannot be assumed that the visitors have installed them – a Helvetica will be missing on most Windows PCs and would therefore neither load nor display them.
Google Fonts, on the other hand, are loaded by default from the Google server and are not cached locally – usually a violation of the GDPR. A corresponding feature to cache Google Fonts locally would be a finger exercise and would mean a GDPR violation less on millions of websites.
Likewise, the numerous, non-context-sensitive setting options in Elementor make it difficult for an average user to attribute the behavior of an element to a certain setting – so it can happen that a background image of a normal user is difficult to find in heavily nested elements – Gutenberg, on the other hand, offers the possibility to easily move up the hierarchy and a background graphic is usually only in the cover Block possible – so the origin can be quickly identified.
Overall, much of Elementor is not thought through to the end: For example, it is advertised that only the icon fonts that are used are loaded with the provided icon element – this brings better performance and PageSpeed.
The concept flaw is serious: Basically, icon fonts like FontAwesome are always bad for the PageSpeed, as they usually compete with the loading of the normal website font and many more icons are contained in a font than are actually needed.
The ideal way would therefore simply be to work with SVGs for icons, as only the icons that are integrated on the respective page have to be loaded.
In the later optimization of a website, one stumbles again and again on unthought functions of Elementor, which lead to crude and unstable solution attempts.
Elementor would actually have the opportunity as a framework to enable qualitatively better websites through best practice implementations. When it comes to fonts alone, you can see that Elementor has not taken the ideal path at any point – one wonders whether fundamental technical questions about the conception of new functions have been asked before.
Therefore, elementor often raises the question of why when a half-baked technical implementation for one of the countless functions has once again been chosen in Elementor. The most likely answer: Feature Creep.
Most users prefer a large range of features to choose from – and are kind about some problems or do not even recognize them. Highly optimized websites have a clear advantage here.
The effort involved in creating a website is usually the same with Elementor and Gutenberg – but the technical excellence clearly lies with Gutenberg in conjunction with our SV100 theme.
Recommendation
Old School or Cutting Edge?
The switch to Gutenberg offers many advantages: High PageSpeed, maximum stability in perspective, as the WordPress Block Editor is the new standard as well as technical top class.
Elementor was important as a competitor and drive for innovation in the WordPress cosmos – the old standard editor of WordPress seemed to have fallen out of time compared to the functionalities of pagebuilders.
But within a very short time, Gutenberg offers immense advantages over Elementor that will make Gutenberg uncatchable in the long run:
In addition to a much higher user base in the long run and support for third-party providers or plugins, Gutenberg does not slow down even with the most complex pages – thanks to React, the performance of Gutenberg in editor mode is unbeatable compared to Elementor.
In the end, the question arises for every user and every WordPress agency:
Why a PageBuilder plugin, if WordPress with the Block Editor delivers a product that is now at least equal.