Elementor, Divi and page builders: the speed cost

What a page builder does

A page builder is a plugin with a visual editor. You drag elements onto a page, and the builder saves the layout and turns it into HTML, CSS and JavaScript when the page is shown. Elementor, WPBakery, Divi and Beaver Builder are the best known. WordPress's own Block Editor does a similar job, and it is part of core.

Builders solve a real problem. They let people without a developer change their own pages, reuse parts, and keep a consistent look. The cost is in the output. To give you freedom, a builder wraps each element in several layers, loads a library of styles and scripts for features you may not use, and often adds a second set of fonts and icons.

What the data shows

The 2025 Web Almanac looked at page builders in its CMS chapter:

• Estimates suggest that around 60% of WordPress sites use a page builder.
• Elementor has the largest footprint, followed by WPBakery and Divi, alongside wide use of the native Block Editor.
• Page builders often produce more complex page structures and larger CSS and JavaScript bundles, which raises performance risks at scale.
• Newer builders have added conditional asset loading, minification and less use of shortcodes. The Almanac says these efforts help, but do not completely close the gap between builder-heavy sites and more tightly controlled ones.
• Elementor's share fell between 2024 and 2025 while the Block Editor's grew. The Almanac reads this as a gradual move away from older builders toward block-native or more performance-focused approaches.
• Builders that cut markup, avoid loading assets everywhere, and work closely with the Block Editor tend to limit the cost best.

Two cautions. These are patterns across many sites, and they say nothing about yours. And the Almanac also reports that the biggest differences among WordPress sites come from how each site is set up, not from WordPress core.

How the cost shows up

Measure your builder's footprint

Test on a copy of the site, and use the same three pages as in the themes and plugins guide: the home page, a content page and a page with a form.

1. List the files. Open DevTools, go to the Network panel, reload, and type the builder's folder name in the filter, such as elementor. Note the number of files and their total size. Do the same for its add-ons.
2. Check the structure. Run the free audit and look at Optimize DOM size, or count the elements with the script in the DOM size guide.
3. Check what is unused. The Coverage tool shows how much of each file ran on the page. A large share of unused code is normal for a builder, but it tells you which files to question.
4. Compare. Build one simple page, such as a heading, a paragraph, an image and a button, twice: once with the builder and once with blocks. Test both. The gap is the builder's base cost, before you add any design. It is a rough tool, but it settles arguments.

Settings and habits that help

Builders keep adding performance options, and the names change between versions, so check the builder's own documentation and settings screen. Elementor's plugin description, for example, lists reduced page structure, improved media loading, lazy loading, faster font loading, optimized loading of front-end files and element caching among its features. These are the vendor's claims, and we have not tested them here. Test each one on your own pages.

Whichever builder you use:

• Switch the performance features on one at a time. Test the layout after each, because some change how a page is built. Keep a note of what you changed.
• Keep the layouts shallow. Use fewer nested sections. A section inside a section inside a section is the usual cause of a large page structure.
• Use fewer widgets of the heavy kinds. Sliders, carousels, tabs, counters, and animated headings add scripts. Use a static image or plain text where the effect adds nothing.
• Skip background video and heavy motion on the first screen. See video without the slowdown.
• Limit fonts and icons. Set the fonts once, globally. Two families with a few weights are enough for most sites. Use only the icon sets you need. See web fonts and speed.
• Be careful with add-on packs. Each pack that loads files on every page has a cost. Use one pack or none.
• Keep the header and footer light. They are on every page, so any weight in them is paid everywhere.
• Use a light base theme. Elementor's plugin page recommends its own Hello theme as a lightweight blank canvas, for example. A heavy theme and a heavy builder together double the cost.
• Keep everything updated. The Almanac notes that newer builders have improved asset loading.
• Add a page cache. It removes most of the server-side cost of building the page for each visitor. See WordPress caching.

Builder or blocks?

There is no single right answer. These questions help:

• Who edits the pages, and how often? If non-technical staff change layouts every week, a builder may pay for itself.
• How much of the site is the same layout? Content that repeats, such as posts and product pages, suits blocks and templates well.
• How far are you from your targets? If a lean builder page already passes the Core Web Vitals, there is no need to move.
• How much does the first screen matter? A landing page that earns money may be worth rebuilding in a lighter way, even if the rest stays.
• What is the cost of leaving? The Almanac notes that older builders have created long-term maintenance and lock-in problems. Content built with a builder's own elements may need rebuilding if you leave.

A common middle path is to keep the builder for a few complex pages and use blocks and a block theme for the rest.

If you decide to move

Do it page by page, starting with the pages that matter most: the home page and the landing pages that get traffic. Build the new version on a copy, test it for speed and for looks, and keep the old addresses working. Move the whole site only if the tests show a clear gain. Do not remove the builder until no page depends on it, or its pages will turn into piles of shortcodes.

Mistakes to avoid

• Blaming the builder for everything. Images, fonts, hosting and scripts from other companies often matter more. Measure first. See what to fix first.
• Switching on every performance option at once. If the layout breaks, you will not know which one did it.
• Buying add-ons for small effects. A tiny effect can bring a large library.
• Leaving old builders installed. If you changed builders, remove the old one once nothing uses it.

Check your own page

Run the free audit on a builder page. Look at Optimize DOM size, Reduce unused CSS, Reduce unused JavaScript and the longest tasks. If the builder's files are among the largest, work through the list above, starting with the heaviest page that gets traffic.

Sources

• CMS chapter, Web Almanac 2025: page builder use, the effects on structure and files, and the variation among WordPress sites.
• Elementor on GitHub: the plugin description with the vendor's list of performance features and its theme recommendation.
• Optimization in the WordPress Advanced Administration Handbook.