We ran Elementor as our default builder for about seven years. We shipped a lot of sites on it, and some are still running today, untouched, doing their job. So this is not a story about a tool that failed us. It is a story about a tool we outgrew, and a newer one (Bricks) that does the parts we care most about better. In 2025 we made Bricks the default for new builds, including a full rebuild of this site. Here is the honest version of why, and the cases where we still open Elementor on purpose.
What actually pushed us off Elementor
It was not one thing. It was a few things, and they all point at the same problem: weight.
Elementor wraps almost everything in nested div containers. A simple two-column section with a heading and a button can ship five or six levels of wrapper divs before you reach any actual content. On a content-light landing page, nobody notices. Put it on a WooCommerce category with 60 products, faceted filters, a mega menu, and a couple of carousels, and the DOM balloons past 3,000 nodes. The browser notices. So does the phone the customer is holding.
That DOM weight is the root of the performance ceiling. We could get Elementor sites into “good” Core Web Vitals territory, but it took work: trimming widgets, disabling unused features, deferring asset loads, WP Rocket tuned hard, sometimes a CDN doing heavy lifting it had no business doing. We were billing real hours fighting the builder’s own output to hit numbers that a leaner page hit for free. Do that across twenty retainer clients and you start asking why the floor sits so high.
Then there was the update churn. Elementor ships often, and for years a meaningful share of those releases broke something on a live site: a layout shift after an update, a widget rendering differently, a quiet spacing change from a deprecated control. We built a habit of staging every Elementor update and clicking through the site before pushing it live, because we had been burned. That is a tax you pay on every retainer client, forever. Not catastrophic. Just constant.
What Bricks genuinely does better
The first time we built a real page in Bricks, the markup is what stood out. You place a section, and you get a section. You decide whether something is a div, a heading, a list. The output reads close to what a developer would hand-write: fewer wrappers, real semantic tags, classes you named yourself. View source on a Bricks page and it looks like a page someone built on purpose.
That clean output shows up directly in performance. On real builds, not synthetic demos, our Bricks pages hit Largest Contentful Paint and Interaction to Next Paint targets with less tuning than the Elementor equivalents needed. Same hosting (Kinsta), same WP Rocket, same Cloudflare in front. The page is lighter to begin with, so there is less to claw back. We will not promise a fixed millisecond number, because it depends entirely on the build, but the starting line sits a lot closer to the finish line.
The global classes and BEM workflow
The part that changed how we actually work is the class system. Bricks lets you build with global classes the way you would in a real stylesheet. We use BEM naming, define a class once (say .bn-work-card), and reuse it everywhere. Change the class, every instance updates. No copy-pasting styles between sections, no per-element styling that quietly drifts out of sync from one page to the next.
For a studio, that is the difference between a maintainable codebase and a pile of one-off elements. A junior can open a Bricks site we built and understand the structure, because it follows the same conventions we would use writing CSS by hand. Elementor’s styling lives mostly on the element. Fine for one page. A slow erosion across fifty.
The builder itself is faster to work in, too. Fewer panels to dig through, a structure panel that actually mirrors the DOM, and a canvas that stays snappy on a long page where Elementor starts to chug. Over a full build, the saved minutes add up to a saved day or two.
Where Bricks still falls short, or is a harder sell
We are not going to pretend the switch is free. There are real trade-offs, and we walk clients through them before we commit.
The third-party addon ecosystem is smaller. Elementor had a decade for plugin authors to build around it. Bricks has a healthy and growing set: Bricksforge, Advanced Themer, and Frames are the ones we actually keep installed, and they run roughly US$50 to 100 a year each. But if you need some niche widget, the odds are higher it exists for Elementor first. Most of the time we do not need it, because Bricks plus those few addons covers what a client actually uses. “Most of the time” is not “always.”
Hiring is the bigger one. Far more WordPress people know Elementor. If a client wants to bring work in-house later, or expects to swap agencies, the pool of developers fluent in Bricks is shallower. We say this plainly. It matters more for a marketing team of six than for a founder who just wants the site to work and to call us when it does not.
And client familiarity is real. A marketing person who has edited Elementor pages for three years has muscle memory you are asking them to throw out. Some marketing and page-template tools still ship Elementor templates as their primary format, with Bricks as an afterthought or not at all. None of that is fatal. All of it is friction you have to be honest about.
The situations where we still reach for Elementor
We did not delete Elementor from our toolkit. We still install it, on purpose, in specific cases:
- The client already runs Elementor with a team. If a marketing team edits the site daily and knows Elementor cold, moving them to Bricks for a redesign is friction we have to justify with more than “the markup is cleaner.” Sometimes the right call is a strong Elementor build that respects what they already know.
- They depend on an Elementor-only addon. If a load-bearing part of their funnel runs on a widget or template system that only exists for Elementor, ripping it out is scope they never asked for. We work with what is holding the site up.
- Fast handoff to a non-technical editor. For a small brochure site where the owner does their own edits and has used Elementor before, the familiarity can outweigh the performance gain. The best builder is sometimes just the one the person using it already understands.
The honest summary: Bricks is our default, Elementor is a deliberate exception. We pick the exception when the client’s situation, not our preference, calls for it. You can see the mix across our recent work.
How we actually migrate a site between them
Here we have to be blunt, because there is a common misconception. There is no clean converter that turns an Elementor site into a Bricks site. The tools that claim to do it produce a mess: the same wrapper bloat you were trying to escape, carried over verbatim, now sitting in a builder that did not generate it. You inherit every problem and gain none of the benefit.
Migrating from Elementor to Bricks is a rebuild. We treat it as one, and we price it as one (typically US$2,500 and up for a small marketing site, more for a WooCommerce store with custom templates). What it actually looks like:
- Audit and inventory. Catalog every page type, template, and dynamic data source. Sort out what is custom, what is plugin-driven, and what is just content.
- Rebuild the design system first. Set up the global classes, typography, and color tokens, then the core templates in Bricks, before touching individual pages. This is where the maintainability is won or lost.
- Rebuild templates, then pages. Header, footer, single, archive, the WooCommerce templates. Then the marketing pages. The content (the words, the images, the products) carries over through the database and the media library untouched. Only the layout gets rebuilt.
- Stage, compare, QA. Build on a Kinsta staging environment, run Core Web Vitals against the old version, check every redirect, and click through on a real iPhone and a real cheap Android before we go anywhere near production.
- Cut over with a rollback plan. Backups in hand, Cloudflare and WP Rocket caches cleared deliberately, Wordfence and the rest of the security stack re-verified after launch.
It is more work than “conversion” makes it sound. The payoff is a site that is genuinely lighter and genuinely easier to maintain, not a translated copy of the old problems. If a migration gets sold to you as a one-click job, that is the tell that you are about to inherit someone else’s bloat.
The bottom line
We moved to Bricks because, on the work we do most (WooCommerce stores and content-heavy marketing sites for US-led brands), the cleaner output and the class-based workflow pay off every week, not just on launch day. We kept Elementor for the cases where a client’s team, plugins, or habits make it the smarter call. Neither one is a religion. The builder serves the build.
If you are weighing a rebuild, or you have an Elementor site that has gone slow and brittle and you cannot tell whether to fix it or replace it, that is exactly the kind of decision we are happy to give you a straight read on. Tell us what you are running and what hurts. Send us a brief and we will come back with an honest assessment, including the cases where staying on Elementor is the right answer. You can also see the range of builds we take on across our services.
