We are always looking for new ways to improve the speed and performance of Elementor websites.
This has been a long time coming. Lately, we have been receiving feedback from our users about the large number of wrapper elements we include in the HTML output of the website builder. The feedback stated that many of the wrappers are not necessary, and they increase the size of web pages and harm performance.
The presence of these wrappers is due to the diverse use of Elementor, the ability to use these selectors in various ways to customize your site, and the omni-purpose of Elementor as a solution for creating advanced websites visually.
Removing wrapper elements from the DOM contributes to more simplified code output, better readability and less complexity. A smaller DOM contributes to increases in speed and performance.
** Warning: Breaking Changes **
We have wanted to address this issue for a while now, and Elementor 3.0 provided us with the perfect opportunity to do so. Elementor 3.0 will bring many changes to the way our users build websites with Elementor, and some of these changes, including the removal of several HTML wrappers from our code, are potentially breaking. This means that when you update the Elementor version in your website from 2.x (or even 1.x, for some very out of date sites) to Elementor 3.x, your website’s appearance and/or functionality could break.
Interested in the changes coming down the road? Read more here
The Wrappers Being Removed
Without further ado, here are the classes of the wrappers being removed from Elementor in Elementor 3.0:
.elementor-inner
Previously used under the main wrapper for each document type (e.g. header, post content, footer), a document’s markup in Elementor v2.9 and below looks like this:
<div data-elementor-type="wp-post" data-elementor-id="1234" class="elementor elementor-1234" data-elementor-settings="[]">
<div class="elementor-inner">
<div class="elementor-section-wrap">
// Section Content
</div>
</div>
</div>In Elementor 3.0+, it will look like this:
<div data-elementor-type="wp-post" data-elementor-id="1234" class="elementor elementor-1234" data-elementor-settings="[]">
<div class="elementor-section-wrap">
// Section Content
</div>
</div>.elementor-row and .elementor-column-wrap
.elementor-row was previously used inside sections. .elementor-column-wrap was previously used under the main wrapper for each column in Elementor.
A section’s markup in Elementor v2.9 and below looks like this:
<section class="elementor-element elementor-element-1234 elementor-section-boxed elementor-section-height-default elementor-section elementor-top-section" data-id="1234" data-element_type="section">
<div class="elementor-container elementor-column-gap-default">
<div class="elementor-row">
<div class="elementor-element elementor-element-c5165a6 elementor-column elementor-col-100 elementor-top-column" data-id="c5165a6" data-element_type="column">
<div class="elementor-column-wrap elementor-element-populated">
<div class="elementor-widget-wrap">
// Widgets here
</div>
</div>
</div>
</div>
</div>
</section>In Elementor 3.0+, it will look like this:
<section class="elementor-element elementor-element-1234 elementor-section-boxed elementor-section-height-default elementor-section elementor-top-section" data-id="1234" data-element_type="section">
<div class="elementor-container elementor-column-gap-default">
<div class="elementor-element elementor-element-1a2b3c4 elementor-column elementor-col-100 elementor-top-column" data-id="1a2b3c4" data-element_type="column">
<div class="elementor-widget-wrap">
// Widgets here
</div>
</div>
</div>
</section>Why We Did It, and Why Now
As mentioned previously, we are always looking for new ways to improve the performance of Elementor websites, and by reducing the DOM that is being output to Elementor websites we are making one more step towards better performance.
We do our best at Elementor to address feedback coming from our community. The complaints about Elementor’s markup being unnecessarily bloated have always been on our radar, but since removing wrappers is a high-potential breaking change, we had to wait for a good opportunity to introduce it.
Elementor 3.0 is a major release. We took the opportunity to introduce substantial changes and improvements to the way our users build websites using Elementor. Introducing breaking changes is something that is traditionally done only in major releases, so we took this opportunity to include the wrappers removal among the many features and improvements coming.
What to Do, How to Prepare
Website Builders, Add-on Developers
We highly recommend you go over your code and look for any uses of the wrapper classes mentioned above. If you use them anywhere, refactor your code to use different wrapper classes that aren’t being removed.
If you have not registered as an Elementor Beta Tester in your Elementor sites, we recommend doing that for sites you want to test Elementor 3.0 on before it is released. You can register as an Elementor Beta Tester in any Elementor site by going to your admin dashboard, then going to Elementor > Tools > Version Control. At the bottom of the version control tab, choose “Enable” in the Beta Tester select box, submit your e-mail address, then click on “Save Changes”.
If you are not yet subscribed to our developer newsletter, we highly recommend subscribing via the subscription form in the footer below. When Elementor 3.0 beta is released, our mailing list will be notified.
Elementor Users
If you are an Elementor user, we highly recommend backing up your website’s files and database prior to upgrading to Elementor 3.x, and keeping them somewhere safe (we recommend downloading a copy of the backup to your computer, or saving a copy in a cloud drive service such as Dropbox, Google Drive, or Microsoft Onedrive).
It is also recommended that you test the upgrade process in a sandbox environment (test site) if you have one, and only upgrade your live site when you are sure you have taken all the steps to make sure that your website will look and function like it did before the upgrade.
Learn more about Elementor 3.0 by reading more about the upcoming changes here.
27 Responses
How do we know which widget the inner section uses? Have you not thought about an automatic migration system?
Looks good!I like this!
This is a big step forward and will take the wind out of the sails of many critics of Elementor. Though I do expect a substantial number of changes to existing sites, simplifying the markup that Elementor produces is a step in the right direction.
I believe if you remove unused CSS and JS you will get better results in improve performance
as you can see in this screenshot Elementor generated 104 + 100 + 30 = 234KB unused CSS and JS
screenshot:
https://prnt.sc/t89ikj
@Sina Shamsizadeh
For Elementor developers, it’s not possible to remove unused CSS/JS as it is an universal (one fits all) platform. Meaning that each of us will use different features/modules when building our page builder sites thus the requirement for elementor to provide the required code for each and every feature they offer.
The way to overcome this issue is by manually editing/removing the unused css/js code using the following online service => https://purifycss.online/, but keep in mind that if in the future you will want to update your design and try to add new features/styles, you will have to restore the original css file in order to apply and obtain desire results (just create a backup copy of original and keep in same folder for this purpose. Also, keep in mind that updating Elementor (and other plugins you have optimized coverage) will overwrite your code coverage fix in most cases, but thanks to purifycss, you will be able to re-optimize css in no time).
NOTE: I don’t recommend messing around with the js coverage tool unless you have substantial JavaScript coding knowledge (https://webperftools.com/js-coverage/).
Hi, Good improvement but what about Unused CSS and JS?
Sadly I don’t think I will continue with elementor if there is a possibility of breaking a website with an upgrade. I think that also goes against WP coding standards with backwards compatibility. Your object orientated approach of Elementor was great, a bit buggy, but still usable and very productive. Having to redo all websites because of your upgrade to 3.0 is stupid and it’s quicker for me to fix your code of your plugin than redo entire websites and saved templates(sections/pages). Maybe rename it XElementor to differentiate it from the original if it’s not backwards compatible. Even lauchparty is shutting down because of your upgrade to 3.0.
Post processor is making utility frameworks possible and I could not agree more with Sina.
This is a great improvement to make websites load faster. Sometimes deprecation of things is needed.
@Shilo Eish Yemini
I am so exited to give 3.0 a test run, but will wait a few more days until initial bugs start to level-off.
Question? In another post/forum, we were discussing the DOM issue and I recall someone from your development team mentioning that platform developers will be shortening/renaming the class name from “elementor” to “el” if I am not mistaken and remember correctly. Why wasn’t this update included as part of 3.0 release?
Also, why doesn’t Elementor implements what other Elementor 3rd party plugin have done in the way of allowing the user module integration on a as required basis?
For example:
if I don’t use animations on my site, allow me to turn animations off thus reducing the amount of files loaded initiated by Elementor.
If I am not using font awesome, I should be able to turn it off via dashboard and also include the option of prohibiting other applications to load it.
Elementor has quite a bit of icon files all loading at the same time and from different locations. It takes some skills/time to unload/purify the ones you don’t need. It would be great if you could reduce the amount of icon files used as 3rd party plugins/themes also load their own font-awesome/icon files.
I would suggest an ON/OFF module load feature for your PRO version (similar to Essential Addons for Elementor, etc.. This will significantly reduce the amount of files/http calls.
http://somup.com/cYjTFf697p
This is a huge plus! Thanks a lot for doing this.
Not only the HTML is cleaner, the whole website performance is much better!
This update is stupid, they could have optimized the code in another way. Many of us ARE NOT experts in code, if I was an expert in code I would not have made websites in elementor, I would have made them in html directly. What I mean by this? That many of us use elementor because it is a VISUAL web builder and front end, this means that we do not look at the code to make our websites with Elementor. Now, with this modification, how does an average user know (from the visual constructor), what things have to change so that everything works well? Here in this document they recommend reviewing the code, but they do not recommend how to do it from the visual constructor. The vast majority of websites are built with sections, inside columns and many times there are interior sections inside those columns, now with these changes that structure is completely broken. It seems to me that you are erring ugly boys!
Why not reduce the size even more? If you’re going to do it…do it fully:
– e-el instead of elementor-element
– e-col instead of elementor-column
– e-sec instead of elementor-section
…and so on. There is so much bloat in this code.
Why I still see these elements in 3.0.5? When this change is coming?
Thanks.
We’ve seen that it creates behaviors that are not compatible with older sites, so it’s currently disabled by default, if you want to try feel free to go > WP Admin > Elementor > Settings > Advanced > Optimized DOM Output > Enable
Ariel,
In my case I enabled the optimized output, it improved a little, but I still receive several items with cls, in the analysis made by Google speed, will we still have improvements? Should I try to manually adjust any code?
Thank you. Keep this optimization / more user optimization preferences up. No need to force extra nodes at every turn.
FYI if you have adjacent CSS in the “Custom CSS” input of the HTML widget, it doesn’t seem to pick it up with 3.0 (where it did before in 2.x). I ended up moving the CSS into a tag inline.
Elementor sites are still very slow in the eyes of Google… and as much as i hate it, that is what counts. A simple page still goes over 1500 DOM’s and Google just seems to hate it. The same page without elementor (ex gutenburg) loads almost twice as fast. Any tips on speeding it up?
Awesome! No matter how much we optimized, those DOM elements were like spped anchors. This is a much needed feature. Keep em coming and let’s make sites as fast as they are pretty!
It appears that the DOM setting in the most recent update is now moved from the advanced to the experimental tab. This capability is classified as being in beta on this latest release. What about sites that have already enabled it in the earlier release? I noticed that the setting has reverted to default, even though it had previously been enabled. Does this mean that the DOM elements that were once removed have now been restored during the update?
Great direction, but please continue with this approach to remove more unneeded DOM elements! The DOM Bloat is still a problem after this little fixes.
NICE！
I’m facing an LCP error on my website https://thehomenkitchen.com, everything was perfectly working fine for me before updating a few plugins, but now the speed score reached 84 from 97 in google page speed insights. I’m using elementor pro version with assets clean up pro + wp rocket. Please give it a look and tell me how I can sort out lcp problem.
Thanks
https://directory.thecookbook.pk/ The CLS value is too high on my website. and its showing elementor issue. unnecessary classes on elementor divs and section. how to remove elementor unnecessary classes. please help
Im having LCP and CLS issue on my site https://directory.thecookbook.pk/ and its showing elementor unnecessary divs and section classes issue. please help and let me know how can i remove unnecessary classes?
How does the removal of wrapper elements from Elementor’s HTML output in version 3.0 impact website performance, and what steps can website builders and add-on developers take to adapt to these changes?