Elementor 3.22 introduces an exciting new widget to simplify website navigation, and multiple performance improvements that will help speed up your website. In addition, this release updates the status of multiple mature experiments.
Performance Improvements
Website speed continues to be one of Elementor’s top priorities. This release introduces multiple performance upgrades, focusing on caching widgets’ output, eliminating external JS libraries, improving Editor performance and more.
Caching Widgets Output
Each Elementor widget has its own logic, and when the page loads, Elementor renders the widget to generate the necessary markup. Multiply this process by the number of widgets on the page to get the computation required to serve the page. More widgets means more server computation and memory usage.
To optimize this process, Elementor 3.22 introduces a new caching mechanism for widgets. Elementor will render the widget once and store the output in the cache. The next time the page loads, the expensive computation won’t occur, as it will use the output from the cache.
Internal testing reveals that by using cached widgets, the memory usage drops from 3MB to 8KB (!). This is one of the most significant server improvements Elementor has ever achieved. The result is less server computation time and a much faster Time To First Bite (TTFB) on the frontend of your website.
Our internal tests show a 33% – 69% reduction in TTFB, depending on different page configurations and the widgets in use. In some cases, when the page had a small number of widgets, the TTFB was reduced from 120-130 milliseconds to 80-90 milliseconds. In other cases, when the page had a large amount of widgets, the TTFB fell from 600-630 milliseconds to 180-200 milliseconds. All tests resulted in faster loading times.
The mechanism has a few exceptions. Elementor can’t cache a widget if one of its controls uses a dynamic tag, as the data may return different values based on the dynamic tag type. Therefore, widgets using dynamic tags are not cached. The same logic applies for display conditions; when using display conditions, the widget’s output won’t be cached.
To prevent false positives in the caching mechanism, Elementor takes it a step further. Some widgets may return dynamic content in the widget code itself, such as widgets that print the user name or a random number using a PHP function inside the render() method. This is not ideal, as cached output for one user will return the same data for another user. For these cases, a new boolean method in the widget class will explicitly instruct Elementor whether to cache the output or not.
By default, all widgets are treated as dynamic widgets, meaning that they should not be cached. This way they are treated the same way they were always treated in all previous versions. However, if the widget has the is_dynamic_content() method return false, Elementor will treat the widget as a static widget and cache its output.
All Elementor & Elementor Pro widgets have been mapped and classified into two groups – static or dynamic. We encourage all addon developers to do the same. By applying a simple method to the widget class, you can boost your Elementor addon performance:
protected function is_dynamic_content(): bool {
return false;
}Please note that this feature is being introduced as an experiment to give external addon developers enough time to update their code and monitor edge cases.
Eliminating External JavaScript Libraries
Elementor uses several external libraries for functionality. As these libraries incorporate vast amounts of functions needed by your website, this inflates the size of the JS loaded on Elementor websites. These “unused JS” metrics negatively impact your website performance.
One of these external libraries is waypoints.js, a very useful library that helps execute JS functions whenever the user scrolls to an element. Elementor uses waypoints in multiple widgets, like the Progressbar, Menu, Table Of Contents etc.
However, nowadays, the native Intersection Observer API helps developers do the same natively, without external workarounds.
Therefore, Elementor will no longer be using this library, replacing it with a single line of native IntersectionObserver() function. This change will help reduce reliance on external libraries, decrease the number of JS assets loaded on the page, and save 18kb (minified 12kb). This should reduce the total amount of “unused JS” on pages that use the widgets mentioned above.
To keep backwards compatibility for third-party Elementor addons that continue to use this library, it won’t be removed from Elementor for several releases. The script is registered but not enqueued, unless an addon developer explicitly sets it as a dependency.
Elementor encourages all addon developers to update their code, refactoring waypoints.js implementation to use the native IntersectionObserver(). Developers that prefer to keep using waypoints.js should add the script to their addon as Elementor will remove this library from its code.
Just-In-Time (JIT) Translation Loading
In the past, WordPress plugins and themes added the translation strings inside the plugin folder. In 2015, the translate.wordpress.org platform was introduced, removing the need to include the translation files with the plugin as WordPress downloads the needed translations to the wp-content/languages folder and updates them automatically. This change not only reduced the plugin size, it also eliminated the need to release new versions just for updating the translation strings.
Later, WordPress 4.6 further improved the way translations are loaded, by introducing the just-in-time (JIT) loading for translations. Plugin and theme developers no longer need to call load_plugin_textdomain() or load_theme_textdomain() anymore.
This change not only eliminated the need for manual translation loading, but it also had a performance benefit. By removing the load_plugin_textdomain() calls, Elementor will rely on the just-in-time translation loading functionality in WordPress itself and ensure translations are loaded when needed.
We would like to thank Pascal Birchler, a WordPress core contributor, for his contribution.
Smaller DOM Size
In the last release, Elementor 3.21, widgets that have no content stopped generating empty HTML elements. This release continues the work, no longer generating empty HTML elements in the Form and Posts widgets.
In addition, boxed containers with inner containers will use less <div> elements automatically when dragging new containers. Read more about this optimization in a separate blog post, Elementor Performance Tip – Reduce your DOM Size to Make Your Website Faster.
Additional Optimizations
If you think we’ll stop here, you would be wrong ; ) We are working on several improvements, and are constantly looking at different opportunities where we can make your website faster.
New Performance Settings Tab
As more performance improvements are introduced and existing performance features mature and merge to Elementor, you should be able to see all these performance optimizations in one place. Therefore, with this release, we’ve introduced a new performance tab.
New Performance Tab
As of Elementor 3.22, the Elementor settings page has a fifth tab containing settings related to Elementor performance. This should allow users to enable/disable different capabilities and test site performance to match the settings the site requires.
Currently, the new tab includes three settings moved from the advanced settings tab – CSS Print Method, Optimized Image Loading, and Optimized Gutenberg Loading.
Future Performance Settings
The features tab has multiple performance-related features; some are early-stage experiments, while others are stable features. When these features mature, they will eventually merge into Elementor. In some cases, the merge completely replaces existing functionality. In other cases, the feature may require users to enable/disable them, giving site owners the ability to control over their website.
A good example is the “Inline Font Icons” feature, which will likely be moved to the performance tab in the near future. It allows the user to choose whether to render icons as inline SVG or load the entire Font-Awesome library and its CSS. Websites that use many icons may prefer to load the font file, while websites that use a few icons probably prefer to load inline SVG. These types of settings will be placed in the performance tab.
Experiments and Features
With the release of Elementor 3.22, three experiments had their status updated and one feature reached maturity and was upgraded to stable status.
Upgraded Features
This release upgrades the default activation status of three beta-status experimental features. The “Display Conditions” and the “Taxonomy Filter” features will now be active by default on both new and existing websites, and the “Optimized Control Loading” performance feature will now be active by default on new installations.
Downgraded Features
Elementor 3.22 downgrades the default activation status for the “Landing Pages” beta-status feature. New websites won’t have this feature active by default. However, existing websites will continue to have this feature active in order to maintain backwards compatibility.
New Stable Features
This release upgrades the “Grid Container” feature from beta to stable status, making it safe to use on all websites. Elementor considers stable features safe to use on live websites, though some edge-cases may still exist.
Off-Canvas Widget
This release introduces the Off-Canvas widget, a powerful tool for creating interactive page layouts. This widget allows web creators to build versatile containers that open via connected links that trigger the Off-Canvas display.
Common Use Cases
The most common use for the Off-Canvas widget is in the header templates, creating a simple list of links for the desktop and a separate Off-Canvas widget for mobile.
Nevertheless, the possibilities are endless. You can create menus, promotions, interactive elements, and more. This new feature has all the benefits of Elementor styling, is flexible and easy to customize, and offers smooth interactions.
Off-Canvas vs. Popups
While Popups are separate Elementor documents, the new Off-Canvas is a widget. To create a Popup you need to go through the Theme Builder, set display conditions and select where it would be displayed. However, the Off-Canvas widget can be simply dragged and dropped onto any page. Keep in mind that Off-Canvas widgets are not reusable like Popups.
Another major difference between the two is that the Elementor Popups markup is generated using JS when the Popup is triggered, while the Off-Canvas markup is rendered on the server, and the trigger only shows/hides the HTML with minimal JS.
These differences are important for performance engineers that need to optimize performance on a per-page basis. For pages that heavily rely on JS and aim to reduce its load, the Off-Canvas widget is likely the preferred choice. On the other hand, to optimize static pages with heavy HTML, you might prefer using Elementor Popups which reduces the initial HTML size by generating promotions on the fly using JS.
To Conclude
Like many previous releases, Elementor 3.22 primarily focuses on enhancing performance to improve overall website speed. The newly added Off-Canvas widget also introduces new possibilities for displaying navigation menus and promotions.
We look forward to Elementor addon developers implementing the new caching mechanism in their widgets, allowing our shared users to benefit from significant performance improvements.
