Introducing Elementor 3.28, a maintenance release focused on foundational improvements. With advanced cache management, and refined APIs, this release streamlines workflows and boosts efficiency. Let’s explore the key changes and their benefits.
Elementor Cache Management
Efficient caching is essential for optimizing performance. Elementor 3.28 doesn’t change the caching mechanism but makes it easier to clear cached data from both the WordPress dashboard and from the frontend. Let’s review what Elementor cache does and how you can improve your workflow.
Elementor Cache
Elementor employs a multi-layered caching system to enhance website performance. Each component implements its own caching strategy. Collectively, they all minimize server computation, resulting in improved performance metrics for your website.
For instance, instead of generating CSS files each time the user visits the page, Elementor generates CSS once, eliminating the need for repeated generation. On the first page visit, a CSS file is generated and stored in the /wp-content/uploads/elementor/css/ folder, and used for all users visiting the page.
Similarly, instead of rendering the HTML for each widget on the page, it renders the HTML once, and stores the HTML in the database. Every future page load bypasses the resource-intensive rendering process. This reduces the overall rendering time significantly.
Another example is how asset dependencies are extracted and stored. Instead of iterating over all the page widgets each time to extract the required CSS/JS, Elementor does it once on initial page load and stores the data in the DB. Every subsequent visit uses cached data.
Clearing & Regenerating Cache
You can clear the stored cache at any time to force Elementor to regenerate the data again. Traditionally, to clear Elementor cache, you had to go to the WordPress Dashboard > Elementor > Tools > General > Elementor Cache, and click the “Clear Files & Data” button.
The issue was that you had to open an additional browser tab to clear the cache and then go back to reload the frontend page. To address this issue and reduce the number of clicks, Elementor 3.28 added a new “Clear Files & Data” button to the “WordPress Admin Bar” in the frontend under the “Edit with Elementor” dropdown menu.
Please note that when clearing cache, Elementor deletes previously cached data. A new cache is then generated for each page only on the next time someone visits that page. Triggering this from the frontend ensures that Elementor not only clears previously cached data, but also regenerates new files and data and basically updates cached data.
Form Fields API Update
Elementor 3.28 has improved the Form Fields API by adding new methods for declaring script and style dependencies. This update also integrates the Form Fields API with the asset caching mechanism, leading to faster page speeds for pages utilizing Elementor Forms.
Custom Form Fields
The Form widget in Elementor Pro comes with a wide range of field types, allowing for easy creation and styling of various forms. To further extend functionality and cater to specific needs, Elementor provides the ability to create custom field types. These could include fields like phone numbers with specific patterns, credit card numbers, signature fields, and more.
Some advanced fields might require JS libraries for handling logic or CSS to display the field in a unique design. For example, Elementor’s date and time fields utilize flatpickr.js to display the date-related data in a calendar. To accommodate custom JS/CSS files for other form fields, Elementor has introduced a Field Dependency mechanism, similar to Widget Dependencies.
Each form field can declare its own style and script dependencies, and Elementor will conditionally load these assets only when the fields are actively used on the page.
API Update
The necessary assets for a form field can be declared using the two following properties:
class Elementor_Test_Field extends \ElementorPro\Modules\Forms\Fields\Field_Base {
public $depended_scripts = [ 'script-handle' ];
public $depended_styles = [ 'style-handle' ];
}Form fields should transition from utilizing the $depended_scripts and $depended_styles properties to the get_script_depends() and get_style_depends() methods. This will align the API with other Elementor components.
class Elementor_Test_Field extends \ElementorPro\Modules\Forms\Fields\Field_Base {
public function get_script_depends(): array {
return [ 'script-handle' ];
}
public function get_style_depends(): array {
return [ 'style-handle' ];
}
}We strongly recommend that all our partners, Elementor addon developers and independent developers, adopt these methods as new best practices. The deprecated properties will eventually be removed.
Performance Benefits
This change goes beyond simple consistency and semantics. By aligning the handling of form field dependencies with that of widget dependencies, Elementor unlocked a significant performance boost. Field dependencies can now leverage the same assets caching mechanism that widget dependencies use.
While previous releases implemented “conditional assets loading” of form field dependencies, based on their utilization on the page, this release utilizes the “assets caching” mechanism which stores the assets in a post meta to eliminate the need for repeated extraction on each page load.
This means that the assets required by field dependencies are now stored and retrieved more efficiently, resulting in faster load times and improved overall performance. This optimization results in reduced server computation and improved Time To First Byte (TTFB) on pages using Elementor Forms.
While the immediate impact may seem minimal since not all pages utilize forms, the continuous migration of components to the new caching mechanisms will incrementally enhance page TTFB with each Elementor release.
Control Level Assets Loading
Elementor 3.24 removed a lot of CSS from your website. Widget styles are loaded conditionally, only if a widget is in use on the page, but there is still more room for improvement. Some widgets load their CSS files but they are still 100% unused. Elementor 3.28 addressed this issue, and Elementor addon developers can also use this technique to make their custom Elementor widgets more efficient.
Reducing Unused CSS
When using the “Text Editor” widget on the page, the widget styles are 100% unused. That happens because the styles in this widget are only for the “Drop Cap” functionality, and in most cases, users don’t use this capability.
To address the “Unused CSS” issue, Elementor can load these styles on the control level rather than on the widget level. These styles will only be loaded if the “Drop Cap” switcher is turned on.
Widget Dependencies vs. Control Dependencies
Each widget can set style dependencies by declaring which CSS files to load when the widget is used:
public function get_style_depends(): array {
return [ 'widget-text-editor' ];
}Elementor has the ability to set style dependencies on the control lever rather than the widget level:
protected function register_controls() {
/* .. */
$this->add_control(
'drop_cap',
[
'label' => esc_html__( 'Drop Cap', 'elementor' ),
'type' => Controls_Manager::SWITCHER,
'label_off' => esc_html__( 'Off', 'elementor' ),
'label_on' => esc_html__( 'On', 'elementor' ),
'assets' => [
'styles' => [
[
'name' => 'widget-text-editor',
'conditions' => [
'terms' => [
[
'name' => 'drop_cap',
'operator' => '===',
'value' => 'yes',
],
],
],
],
],
],
]
);
/* .. */
}The assets argument helps you declare which scripts/styles to load and set the loading condition. In the example above, the widget-text-editor style is loaded when the switcher control is active.
“Text Editor” Styles
In the “Text Editor” widget, Elementor removed the widget dependencies, and replaced them with the control dependencies.
This way, even if the widget is used on the page, the styles are not loaded. Elementor will load these styles only when the page has a “Text Editor” widget, and the “Drop Cap” functionality is used.
This minor improvement removed an additional HTTP request and further decreased “Unused CSS”.
New Visual Choice Control
Elementor 3.28 introduces a new Visual Choice control that visually presents multiple choices, similar to the existing Choose control or the native HTML radio input. However, the new control allows the use of images as choices.
These choices are displayed in a grid layout, and widget developers can adjust the number of columns, from 1 by default to n. Additionally, an optional tooltip appears when hovering over each item.
Usage
Use the following code with your widget, to use the new control:
$this->add_control(
'structure',
[
'label' => esc_html__( 'Structure', 'textdomain' ),
'type' => \Elementor\Controls_Manager::VISUAL_CHOICE,
'label_block' => true,
'options' => [
'grid-3' => [
'title' => esc_attr__( 'Grid: 3 columns.', 'textdomain' ),
'image' => plugins_url( 'assets/img/grid-3.svg', __FILE__ ),
],
'masonry' => [
'title' => esc_attr__( 'Masonry: arbitrary order', 'textdomain' ),
'image' => plugins_url( 'assets/img/masonry.svg', __FILE__ ),
],
'stacked' => [
'title' => esc_attr__( 'Stacked: Single column.', 'textdomain' ),
'image' => plugins_url( 'assets/img/stacked.svg', __FILE__ ),
],
'focus' => [
'title' => esc_attr__( 'Focus: Text only.', 'textdomain' ),
'image' => plugins_url( 'assets/img/focus.svg', __FILE__ ),
],
'grid-2' => [
'title' => esc_attr__( 'Grid: 2 columns.', 'textdomain' ),
'image' => plugins_url( 'assets/img/grid2.svg', __FILE__ ),
],
'stretch' => [
'title' => esc_attr__( 'Stretch: fit available width.', 'textdomain' ),
'image' => plugins_url( 'assets/img/stretch.svg', __FILE__ ),
]
],
'default' => 'masonry',
'columns' => 2,
'prefix_class' => 'some-layout-',
]
);Google Fonts Local Loading
Elementor 3.28 changes the “Load Google Fonts Locally” experimental feature status from Beta to Stable and activates this feature on all websites. This feature completely changes the way Elementor handles Google Fonts. The new method stops loading fonts from Google CDN, thus improving both user privacy and website performance.
How It Works
Elementor scans for Google Fonts used by the page, downloads them to the website, stores them in the /wp-content/uploads/elementor/google-fonts/ folder, and allows the website to load these fonts from the website server.
When Elementor generates CSS files, it references the locally stored fonts, completely bypassing external requests to Google’s servers. Both the CSS and the font files are loaded locally, eliminating requests from external resources.
Mobile Performance Boost
This feature shows very promising results, managing to boost mobile performance by 3-14 percentage points. The more fonts the page uses, the higher the impact. Furthermore, it also solves privacy concerns in European countries.
Improving mobile performance is a challenging task. We don’t usually see low effort, low risk, and high impact features; especially improvements affecting mobile devices. Yet, this feature proves to be a very successful feature. This is why we prioritized it and upgraded the status and activated it on all websites. Measure your mobile performance before the upgrade and after, and share the results with the community.
Developer Advisory
Elementor addon developers are advised to implement the latest standards and make the following adjustments.
Swiper Dependencies
We want to remind developers to update their carousel-based widgets and declare swiper script/style as a dependency.
Since Elementor 3.24, swiper styles are loaded conditionally, and the performance boost was impressive. Since Elementor 3.27, the same process was implemented for swiper script, preparing the ground for removal of this script loading from all pages, and to load it conditionally.
Unfortunately, some Elementor Addons have not yet implemented this change. We advise developers to update their widgets today, and not wait for user complaints.
Here’s a code example of how to declare swiper as a dependency:
class Elementor_Test_Widget extends \Elementor\Widget_Base {
public function get_style_depends(): array {
return [ 'swiper', 'widget-custom-style' ];
}
public function get_script_depends(): array {
return [ 'swiper', 'widget-custom-script' ];
}
}Supporting Older Elementor Versions
Many external developers continue to support older Elementor versions. And that is ok, backwards compatibility (BC) is an important practice.
While keeping BC is fine, we recommend setting compatibility checks with a minimum required Elementor version for your Addon. For instance, supporting all Elementor versions released in the last year (v3.19 and above), in the last 2 years (v3.10 and above), or even 3 years (v3.6 and above).
This recommendation should solve a common practice we try to discourage – supporting older naming conventions set over 20 versions ago, before Elementor 3.5.0:
if ( version_compare( ELEMENTOR_VERSION, '3.5.0', '>=' ) ) {
add_action( 'elementor/controls/register', [ $this, 'register_new_controls' ] );
add_action( 'elementor/widgets/register', [ $this, 'register_new_widgets' ] );
} else {
add_action( 'elementor/controls/controls_registered', [ $this, 'register_new_controls' ] );
add_action( 'elementor/widgets/widgets_registered', [ $this, 'register_new_widgets' ] );
}We advise setting a minimum required Elementor version, and removing all support for older Elementor versions below this minimum supported Elementor version. Search for version_compare() in your code and remove unnecessary BC code.
Elementor’s long term plan is to remove all deprecated code, providing a smaller code base and easier developer experience. This can’t be achieved as long as the ecosystem continues using old code.
To Conclude
Elementor 3.28 focuses on foundational improvements, enhancing performance, and streamlining workflows. With advanced cache management, and refined APIs, this update boosts efficiency and stability. Developers and users alike benefit from faster load times, improved mobile performance, and a more seamless experience. Stay updated to keep your website optimized and future-ready!
