Why We Don't Use Elementor (And Why You Shouldn't Either)

We've built dozens of WordPress sites at amillionmonkeys over the years. Clients often ask why we don't use Elementor or other page builders. The answer is simple: they create more problems than they solve.

Page builders like Elementor promise speed and flexibility. They deliver vendor lock-in, performance issues, and maintenance nightmares. Meanwhile, Advanced Custom Fields (ACF) with a custom theme gives you the same flexibility with none of the baggage.

Here's why we stopped using page builders in 2019 and never looked back.

The Promise vs. Reality of Elementor

Elementor's pitch is compelling: drag-and-drop page building, no coding required, launch sites faster. For agencies churning out cookie-cutter sites, it works. For bespoke development? It's a trap.

What Elementor promises:

Fast site building
No coding required
Flexible design control
Professional-looking results

What you actually get:

Bloated, slow-loading pages
Vendor lock-in that makes switching themes impossible
Content mixed with design in the database
Maintenance debt that compounds over time

We learned this the hard way. In 2018, we built three Elementor sites for clients. All three came back to us within 18 months needing complete rebuilds. The sites were slow, hard to update, and impossible to hand off to other developers.

The Technical Problems with Elementor

Let's get specific about why Elementor creates technical debt.

1. Performance Is Terrible

Elementor sites are slow. Not "needs some optimization" slow. Structurally, fundamentally slow.

Elementor loads its entire library on every page, regardless of what elements you're actually using. Page builders generate significantly more CSS and JavaScript than a lean custom theme approach.

Why it happens:

Elementor inlines CSS for every widget, even unused ones
JavaScript dependencies load on every page
The editor generates nested div soup (15+ divs for a simple text block)
No intelligent code splitting

You can optimize Elementor sites with caching, CDNs, and lazy loading. But you're solving problems that shouldn't exist in the first place.

2. Your Content Is Trapped

Here's the killer issue: content created in Elementor isn't portable. It's stored in WordPress as JSON and custom post meta, not as standard HTML in the post content field.

What this means in practice:

If you decide to switch away from Elementor (and eventually, you will), your content doesn't come with you. Pages show blank or broken layouts. You need to manually rebuild every page.

We inherited a client site with 60 Elementor pages. They wanted to move to a custom theme. Every single page had to be recreated from scratch. The content existed in the database, but it was locked in Elementor's proprietary format.

Technical breakdown:

// What WordPress normally stores (portable):
<h2>Our Services</h2>
<p>We offer web development...</p>
 
// What Elementor stores (not portable):
[{"id":"a1b2c3","elType":"section","settings":{"layout":"boxed"},"elements":[...]}]

That JSON blob is meaningless without Elementor installed. Your content is held hostage by a plugin.

3. Database Bloat Is Real

Elementor stores design data in the database. Lots of it. Every padding value, every color choice, every animation setting.

Elementor sites we've inherited have had databases that are dramatically larger than comparable custom theme sites.

Why this matters:

Slower database queries
Longer backup times
Expensive hosting (database size affects pricing)
Revision history bloats even faster

WordPress already has revision control. But Elementor revisions store full JSON snapshots of entire pages. After months of edits, pages can accumulate many revisions, each storing substantial data.

4. Updates Break Things Constantly

Elementor releases updates frequently. That sounds good until you realize each update risks breaking your site.

Real examples we've dealt with:

Elementor 3.6 changed container behavior, broke 12 layouts
Elementor 3.11 deprecated widgets, required manual migration
Third-party Elementor addons broke after core updates

We spent three days fixing a client's site after an Elementor update changed how flexbox containers worked. Sections that were perfectly aligned suddenly had broken layouts. Not because we did anything wrong—because Elementor changed core CSS classes.

With a custom theme, WordPress core updates rarely break anything. The HTML/CSS structure is yours. You control it. Updates don't change your markup.

5. Developer Experience Is Painful

Elementor's code is impossible to version control properly. Your page designs live in the database, not in code. This creates problems for team development:

Version control issues:

Can't see design changes in Git diffs
Multiple developers can't work on layouts simultaneously
No code review for design changes
Deployments require database migrations

We tried using WP Migrate DB Pro to sync Elementor content between dev/staging/production. It worked 80% of the time. The other 20% resulted in broken layouts that required manual fixes in production.

Debugging is a nightmare:

Page source is auto-generated, unreadable
Can't inspect element markup easily
CSS specificity wars (Elementor uses !important everywhere)
JavaScript errors are buried in minified libraries

Try debugging a layout issue when your HTML looks like this:

<div
  class="elementor-element elementor-element-a1b2c3 elementor-widget elementor-widget-text-editor"
>
  <div class="elementor-widget-container">
    <div class="elementor-text-editor elementor-clearfix">
      <p>Your actual content</p>
    </div>
  </div>
</div>

Five nested divs for a paragraph. Good luck targeting that with custom CSS without using !important.

Why ACF + Custom Theme Is Better

Advanced Custom Fields (ACF) gives you the same flexibility as Elementor without the technical debt. Here's why it's our default approach.

1. You Own the Code

With ACF, you define custom fields in code (or the UI), then create custom templates that use those fields. Your content lives in standard WordPress fields. Your design lives in theme templates.

Simple ACF example:

// Define fields (can be done in UI or code)
if( function_exists('acf_add_local_field_group') ):
  acf_add_local_field_group(array(
    'key' => 'group_services',
    'title' => 'Service Page Fields',
    'fields' => array(
      array(
        'key' => 'field_service_icon',
        'label' => 'Service Icon',
        'name' => 'service_icon',
        'type' => 'image',
      ),
      array(
        'key' => 'field_service_description',
        'label' => 'Service Description',
        'name' => 'service_description',
        'type' => 'wysiwyg',
      ),
    ),
    'location' => array(
      array(
        array(
          'param' => 'post_template',
          'operator' => '==',
          'value' => 'template-service.php',
        ),
      ),
    ),
  ));
endif;

Then use those fields in your template:

// template-service.php
<?php if( get_field('service_icon') ): ?>
  <img src="<?php the_field('service_icon'); ?>" alt="Service Icon">
<?php endif; ?>
 
<?php if( get_field('service_description') ): ?>
  <div class="service-description">
    <?php the_field('service_description'); ?>
  </div>
<?php endif; ?>

What this gives you:

Full control over HTML structure
Semantic, lightweight markup
Version-controlled templates
Portable content in standard WordPress fields
No performance overhead

2. Content Stays Portable

ACF stores content in standard WordPress custom fields. If you switch themes or disable ACF, your content remains intact. It won't be formatted perfectly, but it's not lost.

We migrated a site from ACF to a different CMS last year. All the content exported cleanly because it was stored in standard database fields, not proprietary JSON.

3. Performance Is Excellent

ACF adds minimal overhead. It's just custom fields—WordPress has supported these since version 1.5. No massive CSS/JS libraries, no auto-generated markup.

ACF with custom themes produces clean HTML with minimal CSS and no unnecessary JavaScript. The performance difference is substantial.

4. Developers Can Actually Work Together

ACF fields are defined in code (using acf_add_local_field_group), templates are PHP files, and styles are standard CSS. Everything is version-controlled.

Developer workflow:

Designer creates mockup
Developer builds custom theme template
Developer defines ACF fields
Content editor populates fields
Design changes are code changes (version controlled)
Multiple developers can work on different templates simultaneously

We have three developers working on WordPress projects. With ACF, we can work in parallel without conflicts. Templates are separate files. Merging changes is trivial.

With Elementor, only one person can work on a page at a time. Design changes happen in the database. You can't review them in pull requests.

5. Updates Are Boring (In a Good Way)

ACF is stable. Updates rarely break anything. We've been using ACF since version 4 (it's now version 6). Not once has an ACF update broken a production site.

Why? Because ACF doesn't control your markup. It just provides a clean API for custom fields. Your templates determine the HTML structure. Updates don't touch your templates.

6. Flexible Content: The Secret Weapon

ACF's Flexible Content field type gives you Elementor-style page building without the baggage.

How it works:

Create "layouts" that editors can add/remove/reorder. Each layout is a template partial you design.

// Define flexible content field
array(
  'key' => 'field_page_sections',
  'label' => 'Page Sections',
  'name' => 'page_sections',
  'type' => 'flexible_content',
  'layouts' => array(
    'hero' => array(
      'label' => 'Hero Section',
      'sub_fields' => array(
        array(
          'key' => 'field_hero_title',
          'label' => 'Title',
          'name' => 'title',
          'type' => 'text',
        ),
        array(
          'key' => 'field_hero_image',
          'label' => 'Background Image',
          'name' => 'image',
          'type' => 'image',
        ),
      ),
    ),
    'text_block' => array(
      'label' => 'Text Block',
      'sub_fields' => array(
        array(
          'key' => 'field_text_content',
          'label' => 'Content',
          'name' => 'content',
          'type' => 'wysiwyg',
        ),
      ),
    ),
  ),
)

Then render them in your template:

<?php if( have_rows('page_sections') ): ?>
  <?php while( have_rows('page_sections') ): the_row(); ?>
 
    <?php if( get_row_layout() == 'hero' ): ?>
      <section class="hero" style="background-image: url(<?php the_sub_field('image'); ?>)">
        <h1><?php the_sub_field('title'); ?></h1>
      </section>
    <?php endif; ?>
 
    <?php if( get_row_layout() == 'text_block' ): ?>
      <section class="text-block">
        <?php the_sub_field('content'); ?>
      </section>
    <?php endif; ?>
 
  <?php endwhile; ?>
<?php endif; ?>

What this gives editors:

Drag-and-drop section ordering
Add/remove sections as needed
Flexible page layouts
But: design is still controlled by your templates

Editors get flexibility without the ability to break your design system. That's the key difference.

The Philosophical Argument: CMSs Should Not Give Editors Design Control

Here's the uncomfortable truth that page builder advocates ignore: giving content editors full design control is a bad idea.

This isn't elitism. It's about sustainability and maintainability.

Why Design Control Creates Problems

1. Brand consistency disappears

When editors can change fonts, colors, spacing, and layouts freely, brand guidelines become suggestions. We've inherited Elementor sites where every page looked different because editors had been "experimenting" with designs for years.

One client had 14 different shades of blue across their site. Not because that was intentional—because editors had used Elementor's color picker to create "slight variations" over time.

2. Accessibility suffers

Editors aren't accessibility experts. When they choose colors, they don't check contrast ratios. When they change font sizes, they don't consider readability. When they rearrange sections, they don't think about keyboard navigation.

We've audited Elementor sites and found numerous accessibility issues including color contrast violations, broken heading hierarchies, removed focus states, and missing alt text. These issues occur because editors have design control without design expertise.

3. Performance degrades over time

Editors add animations, hover effects, parallax backgrounds, and video backgrounds because they can. Each addition slows the site. Nobody is monitoring performance metrics or testing on mobile.

We've seen Elementor sites degrade significantly in performance over time as editors add animations, effects, and widgets without consideration for page speed.

4. Technical debt becomes unfixable

When design decisions live in the database (Elementor's approach), cleaning up problems is nearly impossible. You can't do a find-and-replace across templates. You can't enforce design system updates globally. You have to manually fix things page by page.

Fixing brand consistency issues on Elementor sites requires manually updating pages one by one. With a custom theme, global design changes are simple CSS updates.

The Right Division of Responsibilities

Content editors should control:

Text content
Images and media
Section ordering (within constraints)
Meta information (titles, descriptions)
Publishing schedule

Developers should control:

HTML structure
CSS styling and design system
JavaScript interactions
Performance optimization
Accessibility standards
Brand consistency

Designers should control:

Visual design and layouts
Typography hierarchy
Color palettes
Spacing and alignment
Component design

This separation ensures quality, consistency, and maintainability. Page builders blur these lines, giving editors access to decisions they're not equipped to make.

ACF Respects This Division

With ACF, editors get structured content fields. They can:

Add a hero image
Write body copy
Reorder predefined sections
Add CTAs with predefined styles

They cannot:

Change font families or sizes
Modify spacing or padding
Add custom CSS or JavaScript
Break responsive layouts
Violate accessibility guidelines

This isn't limiting—it's empowering. Editors can focus on creating great content without worrying about design decisions. They can't accidentally break the site.

Real example:

We built a site for a marketing agency. They wanted editors to create case study pages with flexibility, but maintain brand consistency.

Our ACF solution:

Custom post type: "Case Studies"
Flexible Content field with 8 predefined section types:
- Hero with client logo and tagline
- Challenge/solution two-column
- Metrics grid (3-4 stats)
- Quote with headshot
- Image gallery
- Video embed
- CTA section
- Related case studies

Editors can add these sections in any order, populate them with content, and reorder as needed. But the design of each section is locked in template files. Fonts, colors, spacing—all controlled by the theme.

Result: 30 case studies published over 18 months. Every single one looks professional and on-brand. No design review needed. No cleanup required.

That's the power of appropriate constraints.

The "But Clients Want Elementor" Objection

We hear this constantly: "Clients specifically ask for Elementor."

They don't actually want Elementor. They want:

Easy content editing
Flexibility without needing a developer
Visual editing (WYSIWYG)
Fast updates

ACF delivers all of this without the technical debt.

ACF Provides Visual Editing

ACF fields appear right in the WordPress editor. Editors see what they're adding in context. It's not drag-and-drop, but it's visual and intuitive.

With ACF Flexible Content, editors see:

Section thumbnails or labels
Add section buttons
Drag handles to reorder sections
Collapsible panels for each section's fields

It's not as flashy as Elementor's live preview, but it's far more usable for daily content updates.

Educate Clients on Long-Term Value

When clients ask for Elementor, we explain the tradeoffs:

Elementor:

✅ Visual drag-and-drop
❌ Slow page loads
❌ Vendor lock-in
❌ Higher maintenance costs
❌ Design consistency issues

ACF + Custom Theme:

✅ Fast, optimized performance
✅ Portable content
✅ Lower maintenance costs
✅ Brand consistency enforced
⚠️ Less flashy editor UI

We frame it as a long-term investment. The site might take slightly longer to build initially (though honestly, not much), but it'll save them money and headaches for years.

While custom themes may have higher upfront costs, the long-term expenses are lower. Elementor sites typically require more expensive hosting for performance, higher maintenance costs due to update issues, and costly redesigns when switching away from the platform. Custom themes reduce these ongoing costs significantly.

Practical Considerations: Making the Switch

If you're currently building Elementor sites and considering switching to ACF, here's what you need to know.

Learning Curve

Elementor: Minimal learning curve. Point, click, drag, drop. No PHP knowledge required.

ACF: Moderate learning curve. You need to understand:

Basic PHP template syntax
WordPress template hierarchy
ACF field types and API
HTML/CSS (but you should already know this)

Honestly, if you're building WordPress sites professionally, you should learn these anyway. They're fundamental web development skills.

The learning curve for ACF is moderate but worthwhile. Once proficient, development becomes faster than navigating page builder interfaces.

When Elementor Might Be Acceptable

We're pragmatic. There are scenarios where page builders make sense:

Use Elementor (or similar) if:

Building a quick prototype or MVP that will be rebuilt later
Client has no budget for custom development
Client insists on it after understanding the tradeoffs
Site will have minimal content updates (one-time launch)
Client's internal team is already trained on Elementor

But be honest about the limitations. Don't pretend a page builder is appropriate for long-term, scalable WordPress development.

Migration Strategy

Moving from Elementor to ACF isn't trivial, but it's worth it. Here's our process:

1. Audit the existing site

Document page templates and layouts
Identify repeating patterns (these become flexible content layouts)
List custom functionality

2. Design the ACF field structure

Create custom post types if needed
Define field groups for each template type
Build flexible content layouts for common sections

3. Build custom theme templates

Create template files for each page type
Implement ACF field rendering
Style with custom CSS

4. Content migration

Manually recreate pages (painful but necessary)
Copy/paste content into ACF fields
Test each page after migration

5. Training

Show editors how to use ACF fields
Document common tasks
Provide video walkthroughs if needed

Migration requires significant time investment that scales with site size, but the long-term benefits justify the effort.

Tools and Workflow We Actually Use

Here's our actual WordPress development stack:

Core tools:

ACF Pro (£49/year per site or £299 lifetime): Custom fields and flexible content
Local by Flywheel: Local development environment
Sage (optional): Modern WordPress starter theme with Blade templating
Gravity Forms: Forms (when needed)
Yoast SEO or Rank Math: SEO optimization

Development workflow:

Design in Figma
Identify content patterns and repeating sections
Define ACF field structure
Build custom theme templates
Style with PostCSS/Sass
Version control with Git
Deploy via CI/CD (GitHub Actions or Buddy)

Editor workflow:

Choose page template
Populate ACF fields
Preview page
Publish

It's clean, fast, and scalable.

Key Takeaways

After building dozens of WordPress sites with both approaches, here's what we've learned:

Elementor creates technical debt - Performance issues, vendor lock-in, and maintenance nightmares compound over time
ACF gives flexibility without baggage - Custom fields and flexible content provide editor flexibility with developer control
Content editors shouldn't control design - Separating content from design maintains brand consistency and accessibility
Performance matters - ACF sites with custom themes are significantly faster than page builder sites
Portability is crucial - Standard WordPress custom fields are portable; Elementor JSON is not
Long-term costs are lower - Custom themes cost more upfront but save thousands over 3 years
Developer experience is better - Version control, code review, and team collaboration work properly with ACF

If you're building one-off sites quickly, page builders might work. But if you're building professional, maintainable WordPress sites that will last years, ACF with a custom theme is the only sustainable approach.

We made the switch in 2019 and haven't regretted it once. Our sites are faster, more maintainable, and clients are happier long-term.

Need help migrating away from Elementor or building a custom WordPress theme? We've built dozens of high-performance WordPress sites using ACF and custom themes. Whether you're starting fresh or migrating from a page builder, we can help you build a site that's fast, maintainable, and scalable. Get in touch to discuss your WordPress project.