Elementor is one of the more popular live page builder plugins for WordPress. It has a free and paid version. Some claim it will change WordPress design. We bet alternative editors change the landscape more.
The Elementor plugin free version is a 1.9M download zip file. It’s 6.9M decompressed.
(Comparison: WordPress is 8.9M compressed, 26.5M decompressed).
Page builder code functions slowdown sites. Page-builder plugin authors load variables from databases. This triggers many slowdowns. How much padding do you need? What color? Border or not? Round images or squares? etc. Configuration decisions and selections run in real time. These repeat the same redundant decisions on every page load.
Look at the installation graph below. Elementor plugin’s active installs dropped off in March. Celebrating crossing 800,000 active installs is fine but indicators don’t say the trend will continue.
1.2M of Elementor is Font Awesome. Why did they include that?
One of the bad things about many page builders is they use short codes. Once you stop using the page builder plugin – for any reason – it messes everything up. Elementor (and Beaver Builder) don’t do that. Yes, some features of Elementor use short codes. But only a few, and those are optional features … not necessary.
Elementor Page Builder
Last updated: 2 week ago
Active installs: 800,000+
Zip archive: 1.9M
Why only the 3 star rating with two skulls? Elementor has a low retention rate. Retention’s calculation is active installs divided by downloads. Test-then-abandonment is not a good sign. Only 12 percent of people who try it keep it activated. Why? We don’t know. Ask Elementor. What’s up with that?
It’s not uncommon for a page builder to add 1M of CSS and JS code to every page on your website (site drag). With the average Internet desktop page weight being 2.3M to 3M, you can see a page builder would use up almost half of that. Most heavier mobile pages we test are around 500k to 750k. Our home page is 130k. The page you are reading now is 206k. You can see that an average page builder would be 5 times that weight – without any content!
Elementor has the capability of working well for responsiveness. But only if the site owner doesn’t mess it up. It also can be fast. The biggest potential hidden gotcha is Font Awesome activation. Font Awesome is an icon font and adds 500+ milliseconds globally (site drag). In this instance, 2 HTTP calls of about 250 milliseconds each. That’s a more horrific speed crime of laziness and apathy.
Install a fresh Elementor plugin in a testing space and you’ll find Font Awesome isn’t loaded. Use one solitary icon on one page – and the whole site gets it. If the theme has Font Awesome activated already, it will get loaded twice. That doubles the site drag to 1 second. There is a free plugin to ensure this doesn’t happen (a fix). https://wordpress.org/plugins/better-font-awesome/ (You select an option to avoid Font Awesome duplication). But we tried it and it doesn’t work. It fails with Elementor.
Want to read a good article that compares how the major page builders affect WordPress speed. We didn’t write it. We wish we did. Read it at Primary Image in a new tab.
Here’s what we’ve learned so far: If you activate Font Awesome (called enqueuing) and then say, “Whoops! That just added a big chunk of page weight.” So you remove the icon from the page. It does not dequeue the Font Awesome icon code. It’s lurking in the background – hidden page weight. The only way to get rid of it is to go into the code (or other trickery like https://wordpress.org/plugins/asset-queue-manager/ plugin) or to uninstall Elementor plugin. Then it will go away. Also, if you reinstall the recently uninstalled Elementor plugin, the invisible weight is back again. Global site drag – every page and post. So once it’s enqueued, it’s stuck on and saved in a database somewhere. Half-second delay potential at least. When you have a 1- to 2-second performance budget, that’s a killer.
More about Font Awesome and why it’s bad for mobile speed (less for desktop) – extreme speed for mobile is our goal. Below:
Links to PagePipe’s articles about the deleterious use of Font Awesome:
- Read the second bullet point under: Modern WordPress Speed Traps.
- Read “How much speed difference does font baggage make?”
- An idealistic but thought provoking Unicode alternative to Font Awesome.
Page weight matters most on mobile. Weight consumes connection resources. Mobile’s a different beast than desktop connections. Desktop is all-you-can-eat connections. So, in most cases, a 20k-weight difference makes little impact in load time. Except on a remote smartphone. Then it does. And it costs extra money for each page. Why does 20k even matter for extreme mobile performance optimization? Isn’t that a puny file size?
Elementor delays page load time very little on an average desktop site. Viewer expectation is a 2-second load time.
An average desktop page speed (8 seconds) is unacceptable for mobile – or anyone for that matter. Average page weight (2.3M to 3M) is especially unacceptable for mobile users. Why? Because mobile viewers expect pages to load just as fast as a desktop. Less than 2 seconds! That necessitates building a 1-second page for mobile to achieve a 2-second load time.
We’re talking about building a 1-second page speed on shared hosting that typically has a 500-millisecond Time-to-First-Byte (TTFB). That is the server overhead or server delay before the page starts to render on screen. You can’t remove or change this. You can only switch to a better (more costly) host. If our performance budget is 1 second, we now only have 500 milliseconds left to load all page assets. About half of weight is usually images. The other half WordPress core, theme, plugins, and written content. Again, we say typical. There are many tricks like using no images. Or stripping webfonts. Etc.
So is adding 20k to every page bad for mobile speed? Under these conditions? Of course.
Posts created with Elementor may have 400k of page weight overhead from scripts.
How much difference Elementor makes to speed and page weight is one of those, “It depends” answers.
In general, from tests, it doesn’t add any more than 40 to 75 milliseconds to global page load time.
Now with that said, Elementor only activates on pages requiring their customization. This is elegance in the name of speed. For example, we doubt blog pages require any customization.
If Elementor isn’t used on a page, the plugin isn’t activated. And jQuery isn’t enqueued either. This is miraculous good news. It means use Elementor only where necessary, not on every page. Plugins like Contact Form 7 activate jQuery everywhere. That’s the ugly norm. Elementor is smart. Plus you can use Elementor’s form builder instead.
Conclusion: When Font Awesome is loaded by a WordPress theme and again by Elementor, you get a double load. You can’t shut it off with the Better Font Awesome Plugin (like we hoped). This may not affect desktop speed much – only page weight. Weight is bad for mobile because bandwidth is more costly. It would be about 150K extra weight worst case. That is bad when your home page is only 100k. Adding another 150k isn’t acceptable by our standards.
Delivering icons as a font is a hack.
Author: Tyler Sticka
We didn’t test with text or image content other than a single icon. (Note we later did some testing with video lazy loading on Elementor.) So our test is weak and half-baked. It only reveals the worst stuff we hunt. If you never select any icons, Font Awesome isn’t enqueued. You’re safe. We’re not testing Elementor more thoroughly at this time. We don’t recommend page builders in general – even good ones. Why? Because site owners easily abuse them and make heavy pages. They can’t overcome the temptation to embellish. We feel page builders encourage negative UX behavior. It’s expressive design overkill. It’s like handing an open bottle of poison to an infant. They can’t resist – the site owner drinks it. Thus the skull-and-crossbones in the rating.
It looks like Elementor adds 4 or more HTTP requests. Minor. The downside to using Elementor is small for desktop sites – other than the learning curve.
We see page builders as a stopgap. Only because the best version of WordPress will be built in the future.
WordPress keeps incorporating features that make whole categories of plugins obsolete in a single day. This trend will continue. Automattic watches what’s emerging in the plugin directory. They’re not stupid. We don’t agree with this competitive business strategy. But the big fish will feign innovation by continuing to eat the little fish – either by acquisition or reverse-engineering.
The only detriment to using Elementor is 40-millisecond site drag added to every page of your site. And enqueuing jQuery can negate gains on fast themes built specifically for mobile use. That is low by comparison to say Yoast SEO 240 millisecond bloat – and Contact Form 7 adds up to 50 milliseconds. Those are popular plugins. Popular usually means heavy and slow. A “nice” plugin loads in 1 millisecond. Is Elementor becoming a popular plugin? Yes. For us that’s a bad sign. Yes, a plugin can be popular and still have a bad retention rate. This is typical of popular caching plugins, too. Test and toss.
For extreme mobile performance optimization, we remove everything possible to reduce site drag.
The catch-22 with Elementor is using Font Awesome icon anywhere on the site. One single icon! It adds 75k globally to the site. And if your theme is loading Font Awesome, also, you’ll get a double load making site drag 150k. Does that slow down your site? It depends.
For us, adding 150k is unthinkable.
Now for some good news:
The Font Awesome bugaboo is a hidden trap. But Elementor plugin uses selective activation. In other words, if a page isn’t built with Elementor, the plugin is not loaded. (But Font Awesome is! What?) This is not typical, usually plugins will load globally on every page and post whether they’re needed or not. This we call “site drag.”
So the goal is only use Elementor on those pages where it’s absolutely needed for customization. This will reduce the number of HTTP requests (calls) significantly. For example, usually blog pages don’t require customization but a home page might use a lot of customization.
Elementor plays nice because of selective activation.
We never want to invest in the Elementor learning curve – or any other page builder or builder theme. We see them as vulnerable. It has nothing to do with speed.
Dissolution of 800,000 Elementor site’s is collateral damage for WordPress.
Why would WordPress incur that bad-PR and offensive risk? Read on.
Page builder weakness isn’t about speed.
Even if Elementor plugin doubles the theme page weight. Does that matter? No. Why? Because heavy plugins like WooCommerce swamp potential small gains fiddling with Elementor alternatives.
80/20 rule. Pareto’s Principle.
We’ve assessed what it costs in time and money to get rid of Elementor on a site. It isn’t worth it. Elementor is a benign *growth*. No speed plugin surgery needed. Other problems for speed are much bigger and more toxic. Elementor is puny and not even worth scratching like a speed itch. It causes us no pain to ignore it.
NOTE: Selective plugin activation of Elementor, with a plugin like Plugin Logic, nukes the site. White pages. Never try that. But we do selective plugin activation elsewhere all the time. Elementor doesn’t do global loading (aka site drag). So that minimizes the need. But if you turn off a page builder on a single page or post the whole site disappears. Meditate about what damage Gutenberg might do to Elementor sites.
We could care less about Elementor. It’s not a tool we’ll ever use. It’s fine if you use it to get web skills you need. It’s OK. No guilt.
We will and do touch Elementor on existing client websites. We never remove it – nor would we want to. What a mess that would be.
We recommended Elementor to a site owner in Germany. He had 5-second load times. He actually made the difficult switch from Divi theme to GeneratePress + Elementor combination. His load time was then around 1-second to London using the same host. Nice!
We recommend Elementor page builder – but we wouldn’t build with any page builder. This guy in Germany couldn’t code any customization. He needed a page builder. Our recommendation was Elementor. We don’t hate Elementor.
“I hired several WordPress ‘speed experts’ before. All failed to achieve decent results. Steve is an expert in his field. His advice helped me understand what was slowing my website down and fix it permanently. My site used to take 5 to 7 seconds to load – and after Steve worked his magic – it now loads in less than 1 second. Thank you!” supboardguide.com Hamburg, Germany
Another big point is: The non-existent Gutenberg is slowing page-builder adoption.
Our speculation is not the demise of only Elementor. It’s the future demise of any WordPress Gutenberg lookalikes, copycats, or even simulators. Gutenberg doesn’t equal Elementor today. But it will in the future – that’s WordPress’ express goal. Not ending Elementor, they’re small potatoes. But nuking WIX, Shopify, and SquareSpace.
This is the answer to why WordPress will burn Elementor: MARKET DOMINATION. They want more. They want to take back the piece of pie WIX, Shopify and SquareSpace took from them.
This narcissistic strategy hurts all page builder plugins and themes. Casualties.
People will discover if Gutenberg works or not. Then we’ll all see what real WordPress landscape changes occur. That won’t happen until Gutenberg is finally released. Face it, it’s a big undertaking. It could be a couple more years. Gag!
Our second most popular article is “Where’s the Twenty-eighteen theme?” We never imagined that article’s longevity.
Gutenberg competition will be a spin-doctor excuse to drop non-profitable loser product. Divi theme, please!
People argue semantics about what is a *true* page builder. Like BeaverBuilder or Elementor or Divi. They think the two universes of Gutenberg and page builders are apart. Barely related at all. Wouldn’t that be dainty?
Page builders are bad because human beings can’t control themselves and are seduced into adding too much. That’s bad for speed. This isn’t Elementor’s fault. It’s the result of human frailty.
From Gutenberg plugin page:
“Gutenberg has three planned stages. The first, aimed for inclusion in WordPress 5.0, focuses on the post editing experience and the implementation of blocks. This initial phase focuses on a content-first approach. …
These foundational elements will pave the way for stages two and three, planned for the next year, to go beyond the post into page templates and ultimately, full site customization.”
Full-site suck-o-mization? Do they mean a page-builder killer? Yep.
Mobile WordPress Speed – without coding!