Why We Stopped Using Elementor for Client Sites in 2026

We stopped using Elementor on new client sites in late 2024 and we have not gone back. Across fourteen migrations we measured an average Largest Contentful Paint improvement of 1.8 seconds and an average drop of six active plugins per site, and the editing experience for clients ended up better, not worse. If you came here looking for a one line answer, that is the one line answer. The longer version is below, including the small set of cases where Elementor is still the right call and we will tell a client to keep it.

I am not interested in the tribal version of this argument. Elementor paid a lot of agency rent for a lot of agencies, including ours, for years. The team at Elementor ships fast and the editor has real polish. The reason we walked away is not philosophical. It is that I sat in front of one too many PageSpeed reports trying to explain to a client why their homepage took four seconds to render after we had spent a month optimizing every image, swapping every font, and toggling every experimental performance flag the plugin offered. The architecture has a ceiling. We hit it on enough sites that I stopped pretending the next round of tuning would fix it.

The site that broke our patience

The decision did not come from a blog post or a Twitter thread. It came from a B2B services site we rebuilt in Q3 2024 for a client whose paid traffic budget was tied directly to landing page conversion rate. Their old site was Elementor. We rebuilt it in Elementor because that is what they knew and we wanted to keep handover friction low. The brief was simple. Faster than the old site, prettier than the competitors, no regressions on the keywords they ranked for.

We hit pretty. We hit competitive. We did not hit fast. After three weeks of work, with WP Rocket configured aggressively, every Elementor experiments toggle flipped, critical CSS generated and inlined, and images served as AVIF through Bunny CDN, the homepage still rendered LCP at 4.1 seconds on a 4G mobile profile. The hero image was 80 kilobytes. The HTML was 18 kilobytes. The render path was choking on widget CSS, on jQuery initialization, on the elementor-frontend bundle waiting to hydrate before the lazy-loaded hero would commit. I spent a Saturday rebuilding the homepage as a hand-coded block theme template against the same hosting and the same images. LCP came in at 1.6 seconds. I sent the client a screenshot on Sunday morning and that was the moment I decided we were done shipping new Elementor sites.

What Elementor actually loads

The pitch for any page builder is that it abstracts the markup so designers can move fast. The cost is that the abstraction never collapses cleanly to the minimum viable HTML and CSS for the page in front of the user. A clean Elementor install on a fresh page with a hero, three feature cards, and a contact form will pull in jQuery and jQuery Migrate, the elementor-frontend script, the elementor-frontend-modules script, Swiper, the dialog and share-link helpers, the eicons font, Font Awesome in at least two style variants, and a stack of widget stylesheets that load whether the widgets are used or not unless you have the improved-CSS-loading experiment enabled and tested.

The DOM tells the same story. A single section with three columns and a heading widget produces, on average, between nine and fourteen wrapper elements before the actual h2 tag the user sees. A Gutenberg block of the same visual shape produces three or four. A hand-coded section produces one or two. Multiply that across a homepage and you are shipping somewhere between two and three times the DOM weight of the equivalent native build, with the corresponding cost in style recalculation, paint area, and INP responsiveness on mid-tier mobile devices. The experimental flags help around the edges. They do not change the architecture. You cannot opt out of the widget wrappers because the widget wrappers are how the editor finds and re-renders the elements you drag.

The plugin sprawl follows the same logic. Once you have committed to Elementor you are usually within a few months committing to Elementor Pro, plus an addons pack like Essential Addons or Crocoblock, plus a forms integration, plus a popup plugin, plus a header and footer builder if you skipped Pro, plus a caching plugin to mask the consequences of all of the above. The active plugin count creeps from a clean ten into the low twenties without anyone making a single bad decision along the way. Each plugin individually is defensible. The aggregate is not.

The 14-site migration: numbers and method

Between January 2024 and February 2026, my team and I migrated fourteen client WordPress sites off Elementor. Eleven moved to a Gutenberg block theme with custom blocks built in ACF. Three moved to a fully custom-coded theme with no block editor at all because the client wanted nothing to do with self-editing and the page count was small enough to justify it. The migrations were not done as a study. We just kept the data because every project has a pre-launch and post-launch performance audit baked into our process.

For each site I took three templated page types as the comparison sample. Home, a service or product page, and a blog post. That gave me forty-two page samples. Pre-migration numbers came from the live Elementor site on the client's existing hosting plan with whatever caching and CDN configuration was already in place. Post-migration numbers came from the rebuilt site two weeks after launch on the same hosting plan and the same CDN, with caches reset before each test. Tooling was PageSpeed Insights for field data, WebPageTest for lab data with the median of five runs from a Virginia 4G profile, and GTmetrix as a cross-check. CrUX field data for INP came from the twenty-eight day window starting two weeks post-launch.

Largest Contentful Paint averaged 3.6 seconds before migration and 1.8 seconds after. That is the headline number, an absolute drop of 1.8 seconds across forty-two pages. Total Blocking Time fell from 410 milliseconds to 90. Total page weight came down from 2.4 megabytes to 1.1. Request count dropped from 78 to 34. Active plugin count fell from a mean of 22 to a mean of 16, a drop of six per site, and on the three custom-theme migrations the drop was closer to ten because the addons pack and the popup plugin became unnecessary. INP at the 75th percentile in CrUX field data improved from 280 milliseconds to 140 milliseconds, which matters more than any lab number because that is what your real users on real Android phones actually feel.

I am not claiming these numbers generalize to every Elementor site on the planet. I am claiming they generalize to client sites built by competent agencies who have already done the obvious optimizations. None of these fourteen sites were neglected before we touched them. Every one of them had caching, image optimization, and a CDN configured. The improvement came from removing the page builder, not from doing performance work that the previous team had skipped.

Where the time goes after migration

The thing nobody talks about when they recommend leaving Elementor is the editing experience for the client after launch. This is the part that scared me for years and the reason we stayed on the plugin longer than we should have. We assumed that taking Elementor away meant taking away the client's ability to edit their own site, and that meant losing retainer-friendly autonomy and creating support tickets every time someone wanted to swap a hero image.

The actual outcome has been the opposite. Gutenberg in 2026 is not the Gutenberg of 2019. With a properly built block theme, ACF block bindings for the dynamic fields, and pattern libraries scoped to the design system, a non-technical marketer can edit a Gutenberg page faster than they can edit an Elementor page because there is no widget panel to navigate, no responsive breakpoint toggle to remember, and no nested column structure to fight when they paste in a new section. We trained twelve of the fourteen migrated clients in a single one-hour session each and the support ticket volume on those twelve sites is meaningfully lower than it was on the Elementor versions.

When Elementor still earns its seat

I promised this would be honest and there is a real short list. If a client has fewer than eight pages, edits content weekly or more, has zero performance KPI tied to revenue, and is the kind of non-technical buyer who feels safer dragging boxes around than navigating the WordPress block editor, Elementor still wins on total cost of ownership. The performance ceiling does not matter when there is no paid traffic and no e-commerce conversion funnel sitting behind the homepage. The plugin sprawl does not matter when the site is small enough that twenty plugins still leave headroom on a $35 managed host. The DOM weight does not matter when the brand has no SEO competitors gunning for the same terms.

That is the entire list. A small portfolio or brochure site, a single weekly editor, no performance KPI, and a buyer who explicitly wants the drag-and-drop experience. If you take any one of those four conditions away, the calculus flips. A client with paid ads needs the LCP improvement. A client with a content team larger than one needs the editorial governance Gutenberg patterns provide. A client with e-commerce is not in this conversation in the first place because Elementor and WooCommerce together compound the problem rather than splitting it.

How we move clients off it without breaking SEO

The SEO question is the one that comes up first on every migration call and it is the one with the most predictable answer. We rebuild the templates first, behind a staging URL, with the same h1 and meta structure and the same URL slugs as the Elementor site. We migrate content into the new templates page by page, not by import, because the import always carries Elementor wrapper markup that defeats the entire purpose. We do a one-to-one redirect map for any URL that has to change, which is usually a small handful. We launch on a Tuesday morning, watch Search Console for two weeks, and we have not had a migration cause a ranking loss that lasted past the third week. The improved Core Web Vitals tend to lift rankings within sixty days on competitive terms, which is a nice tailwind nobody asks about up front.

What we recommend in 2026

For new client sites at WitsCode the default stack is a Gutenberg block theme with ACF-powered custom blocks, a small pattern library scoped to the brand, and a plugin list capped at twelve. For existing Elementor sites hitting the performance ceiling we have described, we run a migration scoped to the templated page types and the global header and footer, leave the client editing in Gutenberg, and document the trade-offs in writing. The work pays back inside a quarter for any site running paid traffic and inside two for any site whose organic rankings are in a contested space. That is the case for stopping. The numbers above are the evidence.