Elementor powered a lot of sites we built and maintained over the years. It was convenient, clients liked the visual editor, and the plugin ecosystem around it was huge. Then we started looking at what it was actually doing to site performance — and we stopped.
This is not an Elementor takedown. It is an honest account of why page builders create a performance ceiling that custom code does not have, and what we do instead.
What Elementor Actually Loads
Open a typical Elementor page in Chrome DevTools and look at the Network tab. You will see multiple CSS files, multiple JavaScript files, inline styles on almost every element, and wrapper divs stacked several levels deep around content that could be a single HTML element.
A basic Elementor page with a hero section, some text, and a contact form can easily load 400–600KB of assets before your actual content renders. On a fast connection that is invisible. On mobile or a slower network it is the difference between a visitor staying and leaving.
Google’s Core Web Vitals score reflects this. Largest Contentful Paint and Cumulative Layout Shift — two of the three metrics Google uses for ranking — are both affected by how much a page builder loads before the visible content appears.
The Specific Problems We Kept Running Into
Plugin conflicts were the most common support ticket we handled on Elementor sites. A WooCommerce update, a caching plugin, a security plugin — any of these could break Elementor’s editor or front-end output in ways that were hard to debug and unpredictable.
The second problem was ownership. When a client’s site is built entirely in Elementor, the layout lives in the database as serialized widget data. Moving the site, changing themes, or switching away from Elementor means rebuilding from scratch. The client is locked in.
What We Build Instead
Custom PHP page templates. No page builder, no visual editor dependency. The HTML is exactly what we write — no wrappers, no injected divs, no JavaScript the page does not need.
For clients who need to update content themselves, we use the native WordPress block editor for post and page content, with custom templates controlling the layout around it. The client edits text and images in a clean interface. We control the structure in code.
The result is pages that load faster, score better on Core Web Vitals, and do not break when a plugin updates. The tradeoff is that changes to layout require a developer. For most of our clients, that is a reasonable tradeoff for a site that actually performs.
Is Elementor Always Wrong?
No. For rapid prototyping, for clients who need full layout control without developer involvement, or for simple brochure sites where performance is not a priority, a page builder can make sense. We still support Elementor sites for existing clients.
But if you are starting fresh and care about speed, security, and long-term maintainability — custom code is the better foundation.
