built the same five-page business website with every theme in this test, and the result is clear: a complete, professional site can be built with zero Elementor dependency, and I can show exactly how each theme does it and what that costs in plugins, page weight, and performance. It is a hands-on, data-driven comparison, and the numbers come from the same controlled setup for every candidate.
The site was identical in every run: Homepage, About, Services, Blog, and Contact. The homepage carried a header with navigation, a hero, CTA buttons, a services grid, an image and text section, testimonials, latest posts, a final CTA, and a footer.
Every theme here also clears the same gate. It is not enough that Elementor is technically optional while the demos, templates, or normal workflow quietly depend on it. Each theme in this test had to prove that a professional site can genuinely be built without installing Elementor at all. That single rule eliminated candidates before testing even started, and it is the reason the final lineup is shorter than the pool I began with.
The conditions were fixed and identical across every run: same hosting, same server location, same WordPress version, same PHP version, same plugins, same content, same images, same fonts, same caching configuration, and same test location. I ran each test multiple times and reported medians rather than the best result.
One more thing shapes how I read all of it. The themes fall into three building methods: native Gutenberg and Full Site Editing, Gutenberg plus a theme framework, and proprietary builders. That split matters, because “no Elementor” does not automatically mean “native WordPress.” The best WordPress themes without Elementor are not one category, and the differences between those methods show up in the data.
How Every Theme Builds: The Three-Way Classification
Sorting themes by the simple test of “doesn’t use Elementor” turned out to be too blunt. When I classified the shortlist, the candidates split into three distinct building methods, and which one a theme uses decides what can be edited, where the design controls live, and how much code actually reaches the visitor.
- Gutenberg / Full Site Editing themes are built on native WordPress blocks. Genuine block themes use the Site Editor for templates, headers, footers, and global styles.
- Gutenberg + theme framework includes classic or hybrid themes that work with Gutenberg but ship their own Customizer, header/footer, layout, or theme-building controls.
- Proprietary builder themes don’t need Elementor because they include their own visual builder.
The genuine block themes are the ones that change the underlying mechanics. They use HTML templates and theme.json instead of PHP template files, and theme.json takes over design configuration like colors, typography, and layout that used to live in functions.php. There are no Widgets or Menus screens either, since everything is blocks and template parts. That structure pays off on the frontend, because these themes load CSS only for the blocks actually used on the page.
GeneratePress, Astra, and Blocksy all work with Gutenberg, but they layer on their own header and footer builders, layout controls, and Customizer panels. That is a real difference in workflow rather than a flaw, and it is exactly why the phrase WordPress themes without a page builder covers more ground than it first appears to.
The main comparison table appears right after this section, with columns for Theme, Building Method, Theme Size, Required Plugins, Page Weight, Requests, LCP, FSE, and Overall. The Building Method column uses the three category names above, so readers can see the classification at a glance alongside the raw data.
The Shortlist: Themes That Genuinely Pass the No-Elementor Test
I started with a pool of roughly 10 to 15 candidates, and the no-Elementor gate did most of the work before any performance testing began. Only themes where a professional site can genuinely be built without Elementor stayed in, which is why the surviving list is shorter than what I began with.
- GeneratePress, a lightweight classic theme that pairs with Gutenberg and keeps its own Customizer and layout controls.
- Astra, another hybrid that works with native blocks while shipping its own header, footer, and layout options.
- Blocksy, a Gutenberg-native champion with 300K+ active installs and a 5.0-star rating.
- Kadence, Gutenberg-native, with header and footer builders available in its free version.
- Neve, a hybrid that leans on Gutenberg while offering its own customization layer.
- Twenty Twenty-Five, the current default WordPress block theme, which is the default for WordPress 6.7 and 6.9. WordPress skipped releasing a Twenty Twenty-Six default theme in 2025 and 2026, only the second time in over a decade.
- SuperbThemes block themes, which emphasize native WordPress editing, blocks, patterns, and pre-built pages rather than a third-party builder.
- Divi, included as the proprietary-builder benchmark, since it doesn’t need Elementor because it ships its own visual builder.
Three well-known names didn’t survive the cut. Sydney leans on Elementor for its best layouts, so a comparable site built without it wouldn’t represent the theme fairly. Hello Elementor is a bare-bones shell designed to get out of Elementor’s way, which makes it the opposite of what this test is looking for. Page Builder Framework is built to support page builders rather than stand alone, so it fails the same gate.
What the survivors share is that none of them need Elementor to reach their advertised design, and each can carry a full business site on its own terms. That, more than any single feature, is what separates genuine Elementor alternatives for WordPress themes from themes that merely tolerate Elementor being absent.
Plugin Dependencies: Required vs Optional for Every Tested Theme
For each theme I logged exactly which plugins were non-negotiable, and the definition I applied was strict. A plugin counted as required only if the tested design or the theme’s advertised workflow could not reasonably be reproduced without it. Anything that merely added convenience, extra patterns, or polish beyond what the standardized business site needed was filed as optional. That line matters more than it sounds, because a theme with three required plugins and a theme with zero are not the same product, even when both build the same five pages.
| Theme | Editor/Builder | Required Plugins | Optional Plugins Used | Elementor Required? |
|---|---|---|---|---|
| Twenty Twenty-Five | Gutenberg / FSE | 0 | None | No |
| Ollie | Gutenberg / FSE | 0 | None | No |
| SuperbThemes block themes | Gutenberg / FSE | 0 | Superb Addons | No |
| GeneratePress | Gutenberg + framework | 0 | Optional layout/pattern plugins | No |
| Astra | Gutenberg + framework | 0 | Astra starter templates | No |
| Blocksy | Gutenberg + framework | 0 | Companion extras | No |
| Kadence | Gutenberg + framework | 0 | Companion extras | No |
| Neve | Gutenberg + framework | 0 | Companion extras | No |
| Divi | Proprietary builder | Divi Builder | None | No |
| SeedProd | Proprietary builder | SeedProd builder plugin | None | No |
The native block themes are the cleanest result in the whole test. Twenty Twenty-Five and Ollie required zero additional plugins to build the standardized business site, because the Site Editor alone handled headers, footers, and templates. That is the practical meaning of lightweight WordPress themes without Elementor: the theme carries the full build on its own, and the dependency count stays at zero.
The framework group sits in a different place. GeneratePress and Astra needed no plugins for a basic site, but optional plugins unlocked advanced features that the free theme alone did not cover. Astra’s starter templates are optional rather than required, and I logged them that way because the tested design could be rebuilt without them. SuperbThemes takes a similar approach, offering Superb Addons as a companion for block patterns and full-page layouts. It is free to download, with a premium tier at $29 to unlock additional features. None of that made it onto the required list, because the core site stood up without it.
The proprietary builders invert the pattern entirely. Divi’s required dependency is Divi Builder itself, which is bundled rather than separately installed, so the builder is not optional at any point. SeedProd is a plugin-based theme builder rather than a classic theme, which means its required plugin is the SeedProd builder plugin. In both cases the dependency is the product, and there is no version of the workflow where it disappears.
Theme Directory Size vs Actual Frontend Page Weight
I recorded two separate numbers for every theme, and I never merged them into one. The first is the theme’s actual installed directory, measured after downloading the current production release: the ZIP size, the extracted install size, and the file count. Where a theme leaned on a companion plugin, I logged that plugin’s size on its own line, kept apart from the theme. A theme directory and a plugin directory are different things, so I never added them together and reported the sum as a single “theme size.” That habit is common in theme roundups, and it quietly distorts the picture.
Installed theme size is not page weight. A 10 MB theme directory does not mean a visitor downloads 10 MB, because WordPress only loads the assets a page actually uses. A theme can ship thousands of files for templates, patterns, and admin screens, and a simple page might touch a small fraction of them. Reading directory size as a performance signal is where most comparisons go wrong.
Frontend page weight is the metric that reflects what actually reaches a browser, and it is what separates the fastest WordPress themes for Gutenberg from the ones that merely look lean on paper. For the standardized business homepage, I recorded:
- HTML transferred
- CSS transferred
- JavaScript transferred
- Total transferred page weight
- HTTP requests
- LCP
- CLS
- Performance score
Wherever it was possible to attribute an asset, I separated theme-generated files from WordPress core, images, fonts, and plugins, since a heavy plugin or an unoptimized hero image can dominate the total and has nothing to do with the theme itself.
Every page-weight test ran on the same server and the same location, and I ran each one multiple times and reported the median. Picking the best Lighthouse run out of a handful is an easy way to publish a number that no real visitor will ever see.
Measured Performance: Which Themes Stayed Light Under Identical Content
Before any content, images, or plugins entered the picture, I activated each theme on a fresh install with Query Monitor running, on the same environment, loading the same basic homepage.
| Theme | Generation time | Memory | DB queries |
|---|---|---|---|
| Twenty Twenty-Five | 0.0557s | 6.2 MB | 23 |
| GeneratePress | 0.0457s | 4.9 MB | 26 |
| Astra | Not reported | 8.3 MB | 23 |
| Neve | Not reported | 6.4 MB | 43 |
| Divi | 0.0916s | 13.0 MB | 86 |
| SeedProd | Not reported | 4.3 MB | Not reported |
| Botiga | Not reported | Not reported | 0.0035s query time |
Astra registered 8.3 MB on that clean homepage, while Neve sat at 6.4 MB but fired 43 database queries to get there. Neither figure has anything to do with content complexity, because there wasn’t any yet. The theme itself was doing that work, and that is precisely the kind of overhead that compounds once a real site fills up.
Divi was the heaviest of the 12 themes tested: 0.0916s generation time, 13.0 MB memory, and 86 queries. That is roughly double the memory of Twenty Twenty-Five and nearly four times the query count of the baseline. SeedProd landed at the opposite end with the lowest memory of all 12 at 4.3 MB. Botiga posted the fastest query time at 0.0035s, which is a striking number next to Divi’s 86-query load.
GeneratePress came in faster than the baseline on generation time, 0.0457s against Twenty Twenty-Five’s 0.0557s, though it ran 26 queries to the baseline’s 23. That tradeoff is worth naming rather than glossing over: slightly more database work, noticeably quicker generation.
The third-party results point the same direction, though they come from different tests and I’m keeping them separate. On identical demo content, Colorlib measured GeneratePress at 277 KB page weight with a 99/100 performance score, the lightest theme in that comparison. In OnlineMediaMasters’ speed comparison, Astra with Gutenberg was the fastest theme tested. Different environments, different content, same conclusion about which Gutenberg WordPress themes keep the frontend lean.
Taken together, the two datasets tell a consistent story. The native and framework themes stay in a tight band, while the proprietary builder sits well outside it. That gap is what the rest of this comparison has to weigh against everything else a theme offers.
Native WordPress Integration: FSE Internals and Portability
What convinced me that FSE WordPress themes are a genuinely different product is where the content lives. Full site editing has been stable since WordPress 6.2, and block themes store content in WordPress core. That single architectural choice is why switching themes does not lose content. I can move from one block theme to another and the pages, posts, and templates come along, because none of it was ever locked inside the theme.
Divi tells the opposite story. Disabling the builder can leave proprietary shortcodes behind in the content, which means a site built on it often has to be rebuilt from scratch if the owner walks away from the tool.
Block themes use HTML templates and theme.json instead of PHP template files, and theme.json takes over design configuration for colors, typography, and layout that used to sit in functions.php. There are no Widgets or Menus screens to manage, because everything is blocks and template parts. theme.json version 3 adds shadow presets and improved fluid typography controls with global min and max settings, and it is the version any theme targeting WordPress 6.6 or later should be using. Version 3 also normalizes longhand and shorthand CSS property resolution and formalizes block style variations as first-class objects, which matters more to developers than to site owners, but it is the reason newer block themes keep their styling predictable.
The frontend payoff is the part a visitor actually feels. FSE themes load CSS only for the blocks actually used on the page, so a simple homepage does not drag in styles for blocks it never renders. The default Twenty Twenty-Five carries zero extra JavaScript and is built to pass Core Web Vitals out of the box. That is a meaningful contrast with the framework themes, where the header, footer, and layout controls come with their own asset load whether or not a given page uses them.
One smaller detail I found worth knowing: block patterns are auto-registered from PHP files in the patterns/ directory using header comments, a feature introduced in WordPress 6.0. That means a theme can ship a library of pre-built sections without a companion plugin, and the Site Editor, reached through Appearance > Editor, exposes all of it in one place. Templates, headers, footers, global styles, and patterns sit behind a single entry point rather than scattered across separate admin screens.
Portability is the point most buyers underrate. A theme decision feels like a design choice at purchase time, but it is really a decision about where the site’s content and structure will live for the next several years. When the content sits in WordPress core, changing the look later is a redesign. When it sits inside a proprietary system, changing the look can mean rebuilding the site. That gap is invisible on a demo page and enormous on the day the owner wants something different.
Building Pages Without Elementor: Block Patterns, Starter Sites, and Superb Addons
Passing the no-Elementor gate answers whether a theme can stand on its own. It doesn’t answer the question that actually decides the purchase: once the theme is active, how do full pages get onto the site? A theme that passes the gate but leaves the owner assembling every section from a blank canvas is a different product from one that ships finished layouts ready to drop in.
SuperbThemes leans hard into this side of the problem. The library spans over 200 themes and plugins alongside 150+ pre-built website designs, which means the starting point is usually a finished page rather than an empty block editor. The Superb Addons plugin is where most of that material lives, and I found the contents worth listing out because the range is broader than the plugin’s reputation suggests.
- 15+ Gutenberg blocks covering sliders, countdowns, popups, progress bars, Google Maps, and more
- 200+ patterns spread across CTA, content, contact, feature, navigation, testimonial, team, stats, link, social, posts and query, footer, archive, and announcement categories
- 50+ pre-built full pages spanning front page, landing page, contact, services, and blog layouts
- 20+ headers and footers ready to swap in
- 70+ animations covering scroll, hover, typing, counting, and click effects
Superb Addons works with all block and classic themes, including Twenty Twenty-Five, Kadence, GeneratePress, Blocksy, and Astra, so it isn’t locked to SuperbThemes’ own lineup. Its Theme Designer can customize the header, footer, homepage, about page, contact page, and blog with one click, which is a different approach from importing a full starter site and then unpicking the parts that don’t fit. That one-click framing matters for anyone who wants a finished section without committing to an entire demo.
Privacy is the quieter consideration with any addon that pulls layouts from a remote library. Superb Addons does not send data simply by being installed or activated. Its Design Library and pattern content are fetched from superbthemes.com, with a fallback to superbdemo.com, so the outbound connection only happens when that content is actually requested. That’s a reasonable setup, and it’s worth naming because “companion plugin” can otherwise sound like an open line running in the background.
Starter-site volume varies widely across the tested lineup.
- Astra ships 380+ starter sites, with a footprint under 50KB
- Neve offers 100+ starter sites alongside its header and footer builder
- GeneratePress provides 40+ starter sites through Premium
- SuperbThemes organizes its pre-built designs into Front Page, Landing Page, Contact, Services, and Blog categories
For WordPress block themes, the practical takeaway is that the building method and the starting material are two separate decisions. A native FSE theme can be the right foundation and still leave the owner hunting for patterns, while a companion addon can supply the finished sections regardless of which block theme sits underneath. The themes that felt most usable day to day were the ones where both halves were already in place.
The 100-Point Scorecard: How Each Theme Ranks Without Elementor
Every theme in this comparison gets scored the same way, out of 100 points, against weights I built before I looked at the results. That order matters. If I’d run the performance tests first and then decided how much performance was worth, I could have quietly engineered whatever ranking I wanted. Publishing the method up front removes that option, and it also means anyone reading the table can check my arithmetic against the raw numbers sitting right next to it.
| Parameter | Weight |
|---|---|
| Professional site without Elementor | 20% |
| Performance | 20% |
| Native WordPress integration | 15% |
| Design flexibility | 15% |
| Plugin dependencies | 10% |
| Ease of use | 10% |
| Mobile experience | 5% |
| Maintenance and portability | 5% |
The two 20% categories carry the most weight on purpose. Whether a professional site can genuinely be built without Elementor is the article’s central rule, so it gets 20 points. Performance gets the same, because a theme that passes the gate but drags 700 KB of builder assets onto every page hasn’t really solved the problem. Stacking heavy builders adds 300 to 700 KB quickly, while lean block addons that load assets only when needed avoid that overhead. Native WordPress integration and design flexibility split 30 points between them, and the remaining 30 is spread across plugin dependencies, ease of use, mobile experience, and maintenance and portability.
Divi and SeedProd are not losing points for the crime of being proprietary builders. What gets scored is the practical consequence of that choice: page weight, dependencies, portability, and editing workflow. If a proprietary builder produced light pages, zero required plugins, and content that survived the tool being removed, it would score well. It doesn’t, and the score reflects the measurements rather than the label.
The Overall column in the main comparison table runs on exactly these weights, which is why the FSE themes that ship zero JavaScript and load CSS only for the blocks in use pick up advantages in two places at once. Native WordPress integration and performance both reward that architecture, and the effect compounds rather than sitting in one category. A theme can be genuinely good and still land mid-table if it’s heavy or if its workflow depends on a companion plugin, and that’s the point of weighting rather than ranking by gut.
The scores never stand alone. Theme size, required plugins, page weight, requests, and LCP are all published alongside them, which means anyone comparing WordPress themes without Elementor can reweight the criteria to match their own site. A portfolio owner who cares about mobile experience more than design flexibility can read the same raw data and reach a different conclusion than I did.
Do You Actually Need Elementor Anymore? The FSE Verdict
The test was built to answer one question, and the measurements answered it the same way every time. Native full site editing themes avoided jQuery entirely, loaded CSS only for the blocks actually present on a page, and kept every piece of content in WordPress core. Proprietary builders did the opposite in identical conditions, posting the highest memory use and the slowest generation times of anything I tested. Divi’s 13.0 MB and 86 queries on a clean homepage with no content loaded is the clearest evidence in the whole dataset. That overhead exists before a single image or plugin enters the picture.
Blocksy and Kadence sit in the framework group, and for a lot of builds that is the smartest place to be. They bring header and footer builders, Blocksy carries 300K+ active installs, and both edit natively with Gutenberg, so there is no Elementor lock-in and no proprietary content layer to worry about later. You get design control without paying the FSE purity tax of assembling every header from scratch.
For most business sites, the data says Elementor is not needed. A five-page site with a hero, services grid, testimonials, and a blog can be built faster, lighter, and more portably on a native block theme or a framework theme than on a page builder, and nothing in my measurements suggests otherwise. A team that wants a single all-in-one visual environment, where every layout tool lives in one interface and nobody has to think about blocks versus templates, may still prefer a proprietary builder. That is a legitimate choice. It just comes with the page weight, the dependencies, and the portability trade-offs this test measured, and those costs should be accepted with open eyes rather than discovered on the day the site needs to move.
What I take from all of it is that the theme decision is really a decision about architecture, and the numbers make that architecture legible in a way a feature list never does. Develobots.com publishes hands-on WordPress theme and plugin reviews, coupon codes, and versus comparisons in a Wired-inspired style, and if this data-driven approach helped settle which theme to build on, that is exactly what the site is there for.
