Before the argument, the measurement.
Take one real page on your site. Record its total transferred size, its number of requests, and its Largest Contentful Paint. Then rebuild that same page, visually identical, without the builder. Measure again.
Do that before you believe anyone, including me. The gap is usually large enough to end the discussion, and it is your gap rather than a number from a benchmark post.
What you will typically find on a builder-heavy page is a stylesheet and a JavaScript bundle loading for widgets the page does not use, several hundred kilobytes of CSS where a few tens would do, and a DOM three to five times deeper than the same layout needs. Deep DOM is not a cosmetic complaint. Layout and style recalculation cost scales with it, and that lands on Interaction to Next Paint.
Be fair about why it got chosen
Elementor solved a real problem, and any replacement has to solve the same one or it will not survive contact with your marketing team.
The problem it solved is this: someone who does not write code needed to build and change pages without waiting for a developer. That is a genuine business requirement, not laziness. A replacement that is technically superior and requires a pull request to change a headline is not a replacement. It is a regression wearing better numbers.
So the question is not "what is lighter". It is "what is lighter and still lets marketing ship a page on a Tuesday".
Option 1: the block editor and a block theme
The native WordPress editor has quietly become capable. Full site editing lets you build templates, patterns and reusable blocks, and the output is close to the markup you would write yourself.
What you gain: no builder framework loading on every page, markup you can read, no licence, and no dependency on one company's roadmap.
What you give up: the fine grained visual control Elementor gives you. Some interactions are fiddlier. If your design depends on complex scroll effects, you will be writing CSS.
Who it suits: most SaaS marketing sites. You have a design system, a handful of section types, and you repeat them. That is exactly what patterns are for. Build ten good patterns and your marketing team assembles pages from them without touching a builder.
This is where I would start for most teams.
Option 2: a lighter builder
If the block editor genuinely does not fit, there are builders that generate far less overhead. Bricks, Breakdance and Oxygen all take the position that the output should be close to hand written markup.
What you gain: a visual editor with a fraction of the weight, and usually better control over what loads where.
What you give up honestly: you are still betting on one vendor. The pool of people who know these tools is smaller than the pool who know Elementor. Migration later is another migration. And a lighter builder in the hands of someone who nests twelve containers is still a slow page.
Who it suits: teams who need visual building, have complex layouts, and have someone who will use it carefully.
Option 3: leave the builder behind entirely
A custom theme, or blocks built for your specific design system.
What you gain: exactly the markup you intend, nothing you did not ask for, and the fastest version of the site that is possible.
What you give up: a developer is involved in anything structural. New section types are development work.
Who it suits: teams where a designer and a developer own the site, marketing edits copy rather than layout, and the design is distinctive enough that a generic tool would fight it.
When the answer is that it should not be WordPress
Worth saying plainly. If your marketing site is maintained entirely by engineers, sits in the same repo as your app, and nobody outside engineering has logged into WordPress in six months, you are paying WordPress's maintenance cost for none of its benefit. That is a different conversation, and I wrote about it separately.
Migrating without losing what you rank for
This is where migrations go wrong, and it has nothing to do with which tool you picked.
Before you touch anything:
- Export your current URLs. Every one. Crawl the site if you do not have a clean list.
- Record your baseline. Rankings for your top queries, organic sessions for your top pages, and Core Web Vitals field data. You cannot tell whether a migration helped if you did not measure first.
- Note every page that earns traffic. These get rebuilt carefully and tested individually. The rest can be done in bulk.
During:
- Keep URLs identical wherever you possibly can. The safest migration changes no URLs at all.
- Where a URL must change, redirect it with a 301, one to one, to the closest equivalent page. Never to the homepage in bulk. That tells a search engine the old page is gone rather than moved.
- Preserve titles, meta descriptions, headings and structured data. A rebuild is not the moment to also rewrite your SEO.
- Preserve internal links. They carry more weight than people expect, and builders often generate them in ways that do not survive a rebuild.
After:
- Crawl the new site and check for broken links, redirect chains and missing titles.
- Submit the updated sitemap and watch coverage reports for errors.
- Wait. Rankings wobble after any significant change. Judge it after four to six weeks, not four to six days. Field data for Core Web Vitals reports on a 28 day window, so that number is not meaningful earlier either.
A concrete plan for a 20 page site
If I were doing this in the order that carries least risk:
Week 1. Baseline everything. Rebuild the design system as blocks or patterns: typography, buttons, cards, the section types you actually use. Nothing user facing changes.
Week 2. Rebuild the homepage and the pricing page on the new foundation, on staging. Measure both against the baseline. If the numbers do not improve meaningfully, stop and find out why before continuing.
Week 3. Rebuild the remaining templates and the pages that earn traffic. Bulk convert the rest.
Week 4. Redirect map, crawl, launch, submit sitemap. Then leave it alone and watch.
Week 8. Compare rankings, traffic and field data against the baseline you recorded in week 1.
The unglamorous part, the baseline and the redirect map, is the part that decides whether this goes well. The rebuild is the easy bit.
Work with me
Want me to check your site? Get a free 5-minute teardown.
I build and fix websites for SaaS and AI companies. Reply within 24 hours.
Get my free teardown