v3.0 Updated Convention: Creating New Widgets (For Improved Performance)

Cover image

As part of our effort to simplify and minimize the markup created by Elementor, we have decided to truncate the prefix we use for any Elementor CSS classes, from .elementor- to just .e-.

This move is joined by another important step in our journey of performance enhancement – reducing the number of wrapper HTML elements used by our widgets and by the system in general.

What does it actually mean?

In all of our new widgets, controls, and all-in-all system markup, we will be prefixing all of our classes with .e-.

We will NOT be changing pre-existing widgets, controls, or any other system elements, in order to allow for backwards compatibility and avoid causing serious problems in existing Elementor websites.

As opposed to the wrapper removal step, this is not a breaking change, so it’s not a big deal – if you see a change in our conventions, we just wanted you to let you know that it’s legit and share with you the reasoning behind it.

How does this affect me as an Elementor user or extension developer?

First of all, there is no need for you to make any changes to pre-existing widgets or system elements. If you are developing extensions that manipulate existing system elements, controls or widgets, and used the .elementor- prefix before – we recommend you to follow this guideline and start using .e- instead in your new developments.


Shilo Eish Yemini
Shilo Eish Yemini
Shilo is Elementor’s Editor Product Lead. He loves innovative products, pays attention to the small details, and is passionate about solving puzzles.

18 Responses

  1. I have no idea whether this feature is in Development or still considering –

    1. Code Splitting not by default but by user action. What i mean is that instead of code splitting by default users can select whether to split the code or not.

    2. Less JS dependencies – right now removing JavaScript is a nightmare because when i tried to remove one JS libraries all the JS wouldn’t load.

    And Thank you for considering Performance

  2. I understand the necessary step to achieve cleaner code on pages that use Elementor. Many of us need a constructor that is solid, flexible, but above all, that does not generate additional code, unnecessary divs, or load js, css that is not being used on the page. One step would be to leave the widgets without styles and we have to assign them from scratch. They could let the user decide if he prefers predefined styles and therefore loads the styles or on the contrary that I generated their own styles and create their own css style sheet. How do the CSS plugins YellowPencil or Microthemer. You can also get inspiration from Webflow at some points.
    I am sure that everything I say and more has been in your head for a long time. But listen to me when I say we need better performance and handling from Elementor. Thanks for reading me. Greetings and encouragement with work! you have my support, at least for now …..
    (sorry my english)

    1. For the backend: The link you posted is exactly what is available in elementor but only for developers (you have to use a code but it’s really simple). So the plugin is just a GUI for it.
      For the frontend: Elementor only loads css/js for widgets used on the site so there will never be unused code.

  3. Finally, this would definitely reduce a lot of unnecessary codes in the CSS, especially the frontend.min.css which currently weighted around 102kb(free) and 200kb for (pro).

    We don’t want to see it grows up to 400kb like Visual Composer just for the CSS alone.

    Please reduce absolute nested selector especially in the frontend.min.css so developer or front-end coder can overrides some of the styling providing more flexibility and customization.

    “.woocommerce div.product.elementor .elementor-add-to-cart–align-right form.cart:not(.grouped_form):not(.variations_form) div.quantity”

    just for 1 style alone…..

    Modular CSS load would be definitely helpful in many way so it would only include necessary styles and scripts.

    Kudos to the developer team who really did a deep thoughts on optimizing this for a cleaner, lighter and flexibility for us.

  4. Oh good, long overdue refactoring and bloat cleanup.
    Some fundamental performance issues which need to start with the DOM.

  5. Great move.

    Please reconsider how you implement HTML5 semantic tags. It should be easy and not relying only on the visual elements like section, columns and inner section (BTW, why don’t you remove inner section and simply have section).

  6. This is amazing news! Adding granular configuration on widgets would also save resources. Please look into this Shilo. Almost all third-party widgets have this feature so I think the foundation should also include it 😀 Thank you for listening to us!

  7. I just just just started using Elementor Pro and was already searching for a reduction of nodes in the DOM as it’s very time consuming to comb through to make tweaks.

  8. Would love to see some improvements regarding the DOM issues, i think that should be Elementor’s first priority.

  9. Wow! Such a tremendous effort that helps us as wordpress developers by a ton! Kudos to the team that put effort in making Elementor plugin heading to a new horizon. Looking forward for more improvements and updates!

  10. Great! I always disliked that “.elementor-” prefix for adding unnecessary bytes.

    How about a toggle in Elementor settings to update all “.elementor-” prefixes to just “.e-” for new Elementor websites?

    It could be launched as an Elementor Experiment.

    Please keep refactoring and cleaning-up more of the core Elementor features, instead of adding new things.


Leave a Reply

Your email address will not be published. Required fields are marked *