Elementor vs. Custom Theme for WordPress Websites

If you’re planning a WordPress site and trying to decide between Elementor and a custom-coded theme, you’ve probably already read that Elementor is slow and that custom themes are expensive. Neither claim tells you much on its own, because the speed difference depends heavily on caching and traffic patterns, and the cost difference depends on how often the site changes and who changes it.

The short answer is that Elementor adds roughly a second to page load on pages that haven’t been cached, and almost nothing on pages that have, according to a July 2026 test that used the same theme and the same server for both builds. Whether that second matters for your site comes down to how much of your traffic lands on uncached pages, whether non-developers need to edit layouts, and how long you intend to keep the site before rebuilding it.

This guide goes through what the speed tests show, what your hosting plan can and can’t do about the difference, the update and security side of running Elementor, and what moving away from it involves later.

What We’re Comparing

Elementor is a plugin rather than a theme, so it runs on top of whatever theme is active, which is usually its own Hello theme. Elementor Pro’s Theme Builder lets you design headers, footers, archives and WooCommerce templates in the visual editor, but those designs sit on top of the active theme’s templates instead of replacing them, and Elementor’s own documentation says Theme Builder work can only be exported as Elementor JSON, not as a regular theme ZIP. Every page you build is stored as JSON in the wp_postmeta table, which becomes relevant once you look at migration.

A custom theme keeps its templates and stylesheets in files inside the theme folder, either as a block theme configured through theme.json and edited in the Site Editor, or as a classic theme built on PHP templates. In both cases the presentation layer is code that can live in Git, which is the main structural difference between the two approaches.

One version note before the numbers. Elementor 4.2.4 requires WordPress 6.8 or higher according to its WordPress.org listing, while Elementor’s own help centre still says 6.5, so use the higher figure when planning a new site.

What the Speed Tests Show

There’s no single speed figure for a custom theme, because one custom theme might ship 20 KB of CSS and no front-end JavaScript while another ships three megabytes of frameworks. The useful question is how much Elementor adds when everything else is held constant, and there are three sources worth looking at.

Controlled tests

RankPlot’s July 2026 benchmark is the most controlled test currently available. They kept the Astra theme, built an article page and a landing page first in native blocks and then in Elementor, and ran 80 valid Lighthouse reports across mobile, desktop, cached and uncached conditions, reporting medians rather than best runs.

The request counts explain the gap. Astra with native blocks made 5 front-end requests for about 37 KB, while Astra with Elementor made 18 requests for about 120 KB, and once the page was cached both dropped to around 18 to 20 KB transferred, which is why the cached LCP figures sit within a few percent of each other. RankPlot is clear that this measures the builder layer on top of Astra rather than a hand-coded theme, and that it doesn’t include WooCommerce, ad scripts or cookie banners, so native blocks stand in for a lean theme here without being the same thing as a custom-coded one.

Kinsta ran a similar comparison using the same theme and demo content on the same hosting, and Pingdom reported around 905 KB and 19 requests for the Gutenberg build against 2.5 MB and 48 requests for Elementor, with load times of 1.32 and 1.93 seconds and PageSpeed Insights mobile scores of 93 and 81.

Field data from live sites

PageSpeed Matters matched HTTP Archive’s builder detection against Chrome UX Report data from May 2026 for about 2.1 million WordPress sites, counting a site as passing only if all three Core Web Vitals were in the good range at the mobile 75th percentile. Elementor sites passed 30.0% of the time, Block Editor sites 41.5% and Site Editor sites 43.8%. On LCP alone, 44.8% of Elementor sites were good compared with 65.0% for the Block Editor, while INP was between 92% and 97% good for every builder, which means the Elementor gap is almost entirely in loading rather than in responsiveness.

This data doesn’t prove that Elementor causes the gap, since Elementor sites tend to have different owners, plugin stacks and hosts than sites built by developers on native blocks. What it does show is that the population of live Elementor sites performs measurably worse, by a margin too wide to attribute to hosting alone.

Custom theme results

Mark Yudt’s case study is one of the few direct comparisons of the same design built as a custom theme and as an Elementor site. The custom theme scored 96 on mobile PageSpeed Insights against 62 for Elementor, and GTmetrix LCP was 707 ms against 3.6 seconds. The custom build was still 2.81 MB and 63 requests, though, against 4.03 MB and 83 for Elementor, because removing the builder overhead left the same images and scripts in place. The theme sets the minimum page weight and your images, fonts and plugins decide the rest.

What Hosting and Caching Can Do About It

A page cache serves finished HTML without running PHP, and a CDN puts that HTML and the static files close to the visitor. WP Rocket, LiteSpeed Cache and most managed hosts’ built-in caching all do the first part, and together with a CDN they turn a 2,361 ms Elementor page into a 969 ms one for anyone who hits a cached copy. On a site with a dozen pages that get steady traffic, nearly every visitor hits the cache and the Elementor cost mostly disappears.

The visitors who don’t hit the cache are the problem. Someone arriving from Google on a page that hasn’t been requested in a while, or on a page the cache just cleared after an edit, gets the full uncached load, and those are the visitors Google is measuring. Chrome UX Report samples real users at the 75th percentile, so on a search-driven site with hundreds of pages a large share of the sampled users land on something uncached.

A better hosting plan improves Time to First Byte, and moving from shared hosting to a VPS with tuned PHP-FPM and Redis takes 100 to 300 ms off TTFB, with LCP moving alongside it. We went through the tiers in this article, and the website caching guide covers the cache layers in more detail. What a better plan can’t change is DOM size, CSS parsing or the number of requests the browser has to make before it can paint, because those happen on the visitor’s device after the server has finished. An Elementor page on a $150 a month dedicated server still ships 18 requests before content on an uncached load and a mid-range phone still has to process them, so hosting can hide the extra weight for cached visitors but can’t remove it.

Agencies that build custom WordPress sites make this argument regularly. Tastic Marketing, which builds custom-coded WordPress and WooCommerce sites, says on its web design page that WordPress’s reputation for being slow comes from bloated page builders and untested plugin stacks rather than from the platform itself, and that a custom theme with a deliberate asset list starts from a floor a builder runtime can’t reach. The RankPlot numbers on uncached pages support that position.

What Elementor Has Fixed Since 2021

Elementor has put several release cycles into performance, and the older tests that still get quoted don’t describe the current plugin. WP Tavern reported a 2021 same-design test where Elementor scored 46 on mobile and 83 on desktop in PageSpeed Insights against 94 and 99 for Gutenberg, and a rebuild of Elementor’s own homepage produced 356 div elements and 99 KB of markup in Elementor versus 77 divs and 28 KB in Gutenberg. Those results predate everything below.

1. Improved Asset Loading

Elementor now loads widget CSS and JavaScript only for the widgets that appear on a page instead of shipping the whole library everywhere, which is the biggest single fix and is on by default in current versions.

2. Flexbox containers

Containers replaced the section-and-column structure responsible for most of the nested-div bloat in the 2021 markup test, though sites built before containers and never migrated still carry the old structure.

3. Inline font icons and lazy background images

Smaller changes that cut requests on pages with icon widgets or hero backgrounds.

4. Element caching

Still experimental, this caches rendered widget output so that dynamic widgets don’t rebuild on every request, and it’s worth enabling on pages with loops and dynamic tags after testing it on a staging copy.

If you’re already on Elementor, go to Elementor, Settings, Features and check that Improved Asset Loading and Optimized Gutenberg Loading are enabled, and if the site was built in 2022 or earlier, check whether it still uses sections and columns, because moving to containers is the one change that reduces DOM size rather than just request count. These fixes shrank the gap from the 50-point PageSpeed collapses of 2021 to a few hundred milliseconds and a dozen requests, but they didn’t close it, since RankPlot tested current Elementor with these features available and still measured about a second on uncached mobile loads.

Updates and Security

On 19 August 2026, Elementor released Pro 4.2.2 to fix CVE-2026-32475, an unauthenticated file upload vulnerability rated 9.8 on CVSS that affected any site with a published Elementor Pro form containing a non-required file upload field. Attacks began the same day the patch came out and Wordfence reported blocking more than 190,000 attempts. Patchstack lists 40 patched vulnerabilities for Elementor core and 15 for Pro, with none currently open.

That count is normal for a plugin with 10 million installs, but a plugin with 10 million installs is also exactly what attackers scan for, which means an Elementor site that delays updates is taking a real risk rather than a theoretical one. A site with auto-updates on and a firewall in front of it was fine on 19 August, while a site with updates paused because a previous update had broken a layout was not.

There’s a second update dependency that people miss. Elementor core and Elementor Pro need to stay compatible with each other, and Elementor warns that if a Pro subscription lapses, Pro stops updating while the free plugin keeps going, and the mismatch causes breakage. Pro costs $60 a year for one site on the Essential tier, $84 for Advanced Solo and $108 for three sites on Advanced, so the site’s front end depends on a subscription staying active.

A custom theme swaps that for a different responsibility, since no vendor means no vendor patches and every form handler and database query is code your developer wrote, secure only if they handled input validation and output escaping properly. The attack surface is smaller and the person responsible for it is closer to you, which is an advantage only if you have a developer on retainer. Whichever way you build, run one of the website security tools we reviewed.

Moving Away From Elementor

Elementor to Elementor is simple, because templates, site parts, content and settings all export and import through the built-in tools, and moving hosts is a normal WordPress migration with one extra step. Elementor stores some URLs inside its generated CSS, so after a domain change you run its URL replace command and regenerate the CSS, otherwise background images keep pointing at the old domain.

Elementor to anything else is a rebuild. Layouts live as JSON in postmeta and the Theme Builder can’t export as a theme, so there’s no conversion path, and while posts, custom post types, taxonomies and custom fields survive, the presentation doesn’t. Every template, header, footer and archive gets rebuilt in blocks or in theme files, every Elementor form gets replaced with a forms plugin or custom code, and popups get replaced too. If you deactivate Elementor before that work is finished the pages render blank, because the post content field for a builder page is usually empty.

If you’re starting on Elementor and think you might leave, keep your data out of the builder by putting custom post types and fields in a plugin or in ACF rather than in Elementor-only widgets, since anything that only exists inside a widget is something you’ll retype. Our guide to custom WordPress development covers what the rebuild involves.

Conclusion

Elementor is the right choice when non-developers need to change page layouts regularly, most of your traffic is returning visitors on a small number of pages, and you’re on a host with a proper page cache and CDN, because in that situation the uncached penalty will rarely be the thing that hurts you.

A custom theme is the right choice when your traffic comes from search across many pages, when Core Web Vitals affect revenue, or when you expect to keep the site for more than a few years, because it starts from a lower page weight than Elementor can reach on an uncached load and doesn’t tie your front end to a vendor’s patch schedule.

Either way, run PageSpeed Insights on a representative page with caching cleared before you decide, because the uncached number is the one that tells you which situation you’re in.