In the past, this JS file was loaded on all the pages, even when it was not required. Many widgets use external JS libraries – the most notable example being the Swiper.js library. Next, we aimed to improve the way widgets consume external libraries.
Again, we managed to reduce the total JS files that each page loads. All frontend widget functionality was split into smaller chunks of JS to allow Elementor to load only the scripts being used on the page.
#Animate it elementor pro#
This method was so efficient that we applied the same solution on Elementor Pro 3.1.
#Animate it elementor code#
A simple solution if you think about it, but it required an extensive code rewrite. Elementor checks what widgets are being used on the page and only loads their JS files. This had a huge impact on page speed as the file is loaded on every page. As a result, the general frontend JS file became much smaller. Starting from the 3.1 release, we split our frontend JS into small pieces, giving each widget its own JS file that contains its own logic. Previously, all widget functionality was loaded regardless of whether or not the widgets were used on your page. Now, these files load dynamically based only on the functionality used on the page. We did this by changing the way Elementor loads JS files that are only responsible for individual widget functionality. As a result, each release introduced a number of new techniques that changed the way Elementor loads assets, thereby boosting page performance.Įlementor 3.1 focused on handling JS in order to improve website performance. We split our focus to JS and CSS, choosing to emphasize one or the other on each release. We mapped all the CSS, JS & Font files loaded by Elementor and tried to apply different techniques to reduce their sizes, measuring the performance impact for each release.
One of the main issues that received special attention is frontend assets loading. This went beyond simple file minification as we implemented new techniques that change the way Elementor works internally. Previously, we implemented DOM improvements, optimized dynamic values rendering, added server-side improvements, and more.Īdditionally, we managed to reduce the size of the page generated by Elementor. Many factors affect performance which is why each component is addressed individually and as a group to gauge all of the variables’ overall impact. Let’s dive in! Activate “Improved Asset Loading” experiment Scope – JS, CSS & Font Loading This improves page speed and makes your website run faster by removing unused CSS, reducing duplicate code, applying dynamic assets loading, and so much more. In the most recent releases, we have managed to apply new techniques to how Elementor loads CSS, JS, and Font files. This effort stretches over several versions, so this post will cover the most significant changes we’ve made, focusing on front-end assets loading. While some of these changes are integrated seamlessly into the Editor, others are marked as experimental features.Īs performance improvements have become an even higher priority, we wanted to take you through the changes we’ve implemented in recent versions and, more importantly, discuss how it directly impacts you and your client’s website. With each new release comes performance improvements, inspired by both user feedback and internal research to ensure we’re covering the most important areas. This is why the Elementor engineering team is always working on new ways to make your website run faster. Performance is important to you, which means it’s important to us.