Read this first, because it changes what the rest means
The design already existed. Before any of this started there was a finished homepage: hand-built static HTML, one stylesheet, one JavaScript file. Thirteen sections in it, with a parallax hero, a counter that pins while you scroll past it and a timeline scrubbed by scroll position.
What happened here was a refactor. The same finished front end was rebuilt into six WordPress themes, copying that stylesheet and that script across without editing either line. Nothing was designed. No layout decision was made. No colour was chosen.
That distinction matters because of the second thing you should know.
Claude built these, and I am going to be specific about which Claude
All six builds were done by Claude Opus 5, running at high effort. Not by me, and not by hand.
Fable was the obvious choice and I know it exists. I used Opus because I was out of Fable credits for the week. That is the whole reason, and I would rather say it than imply some considered model evaluation happened.
Opus 5 did the job well. I am not comparing it to Fable, because I never ran Fable on this and I have no data. What I can tell you is what it produced: six builds that reproduced the reference with zero differing pixels, controls run that nobody asked for, and more than a dozen corrections that the builds caught in their own work and in mine. One build volunteered that it had hard-coded the most important section on the page and made it uneditable. Another caught me publishing a wrong figure to five other builds. A third ran the one experiment the others had skipped and proved a pixel discrepancy three separate builds had each blamed on themselves was actually the browser.
That is the argument for telling you. The rigour is the product here, and hiding how the work was done would remove the most interesting thing about it.
How long it took
The five refactors ran in parallel and finished in three and a half hours, from first file to final written report. Each individual build came in under three.
Three things have to travel with that number or it misleads.
Divi is not in it. Divi was the original build, back when the design was still being worked out, and it took four days. The three-and-a-half-hour figure is for the five refactors of a finished design.
Most of that time was not building. It includes verification, the performance controls and a full written interview per build. One build reported roughly seventy minutes to a pixel-identical front end and about the same again on verification alone. The building was the smaller half.
And agent time does not convert to human time. Every build flagged that without being asked. Much of it is parallel work no person does. The useful figure is the ratio between the phases. The total on its own tells you very little.
So: which WordPress theme works best with Claude?
That is the question this can actually answer, and almost nobody has evidence for it.
Every build wrote down what fought it. How many workarounds it needed before it could start. Whether the theme’s class names collided with the design’s. Whether the hooks it needed existed. Whether the theme’s defaults had to be evicted first.
That is a real measurement of how well each theme cooperates with an agent. It also turns out to be useful if you never touch an AI tool, because the things that slow an agent down are the things that slow a person down: silent failures, missing hooks, invisible defaults and errors that look exactly like success right up until someone opens the page.
Here is the short version
I expected to find out which theme reproduces a design most accurately. That question has no answer, because all six hit zero. Not close. Zero differing pixels across 76 million pixels in one build’s measurement, at every screen width tested.
So the interesting question changed. If they can all reproduce the design, what separates them? What each one charges you before you write a line of your own code, and what it quietly does to your page once you start editing.
One more thing up front, because it shapes everything below. Every build here ended up switching its own platform’s payload off to reach its best numbers. That is the finding that mattered most, and it is the one nobody set out to look for.
Each platform has its own write-up with the full numbers for that build, if you would rather go straight to the one you are deciding about:
- Elementor vs WordPress with Divi
- GeneratePress vs WordPress with Divi
- Kadence vs WordPress with Divi
- Astra vs WordPress with Divi
- The WordPress block editor vs Divi
Two earlier builds of the same design sit outside WordPress entirely, in Craft CMS and in Framer.
Ten of the failures we hit along the way never produced an error message of any kind, and those are collected separately in ten silent failures.
If you are choosing between two of them for a project rather than reading all six write-ups, each pairing has a shorter decision page with the pricing on it:
- Divi versus Elementor
- Divi versus GeneratePress
- Divi versus Kadence
- Divi versus Astra
- Divi versus the block editor
The result nobody expected
| Build | Rendered markup | Pixel divergence |
|---|---|---|
| Divi 5 | matches the prototype | 0.000%, zero pixels differ |
| GeneratePress | byte-identical | 0.000%, zero pixels differ |
| Elementor free | byte-identical | 0.000%, screenshots identical files |
| Astra free | byte-identical | 0.000% across 76,097,716 pixels |
| Kadence free | byte-identical | 0.000%, screenshot files identical |
| Twenty Twenty-Five | identical but for two wrappers core forces | 0.000% |
Divi is the reference build. It came first, and it is the one I had already written about. It is also the one row in that table measured on live hosting rather than on a local copy, so treat its markup cell as the same result arrived at by a different route.
Every one of them reproduced it. That is the part I did not expect, and it is worth saying plainly: on a design that already exists, fidelity is not a reason to choose between these platforms. They can all hit the mark.
So the question of which one is most accurate has no winner. It has six. What separates them is everything that happens after the design is on the screen.
Divi pulls ahead in two places. It shipped the finished state of its animations from the start, and that approach was later moved into the prototype so every build inherited it. The fix that brought the rest up was modelled on what Divi was already doing, and it went into the prototype so every build inherited it. And it modelled repeated content properly from the beginning, where one of my builds started with 145 separate fields for what should have been a query. As that build put it afterwards: Divi thought about editing ergonomics and I optimised for a diff.
What each platform charges you before you write a line
This is the measurement I would want if I were choosing, and it is the one nobody publishes.
Each build guarded its own optimisation behind a temporary switch, scored the page with the platform’s stock payload in place, scored it again with the payload trimmed, then removed the switch and confirmed nothing had changed. Same page, same content, same fonts. The only variable is what the platform ships on its own.
| Platform | Stock | Trimmed | What the payload costs |
|---|---|---|---|
| Elementor | 90 | 98 | 8 performance points and 1.1 seconds of load time |
| Kadence | 97 | 98 | 1 performance point, and 4 accessibility points |
| Astra | 98 | 98 | nothing measurable in speed, a great deal in accuracy |
| GeneratePress | 98 | 97-98 | nothing measurable, about 7 KB |
| Core WordPress | 98 | 98 | nothing, 10 KB, zero variance across every run |
Three lightweight stacks at or near zero, and one page builder an order of magnitude worse. The boundary is not that WordPress is slow or that themes are bloated. It is specific, and it sits at the page builder.
Elementor charges real money. Eight Lighthouse points and 1.1 seconds of largest contentful paint, on a page that uses no Elementor feature whatsoever. Stock, this build would have failed the threshold I set. Its own summary was blunt:
Elementor is an editor, and on this build it earns its place in the editor and contributes nothing to the frontend except weight, which we removed.
Kadence charges almost nothing in speed and four points in accessibility, which I did not see coming. Stock, the page drops to 93, because Kadence’s own button styling changes the line height on a control the prototype styles itself. The announcement bar’s dismiss button ends up 22.94 pixels wide against a 24 pixel minimum. The theme’s stylesheet made the page measurably less accessible than no stylesheet at all, on an element it never intended to touch. One pixel of arrow.
Astra charges nothing in speed and everything in accuracy. Its entire payload is two requests and 14 KB, and removing it changes the performance score by nothing at all. But put it back and the layout breaks: 0.62% divergence on desktop, and on mobile 13.83% with 40 extra pixels of page height. For Astra, the trimming bought fidelity rather than speed. No other build’s measurement separates those two things.
And here is the control that reframes all of it. I scored the original static HTML page the same way. It came out at 91 on mobile.
Every WordPress build was seven points faster than the hand-written static page it was copied from. It ran the same markup and the same stylesheet, with the same JavaScript file and WordPress added on top. That is not the result anyone expects, and it is the strongest answer I have to the claim that WordPress is inherently slow. What is slow is what you put on top of it, and the measurements above say exactly where that starts.
One more finding, and only one build could produce it. Twenty Twenty-Five is the only build whose “stock” is WordPress itself rather than a third-party theme. On the tap-target audit it scores a pass in every single run, stock and trimmed, on both presets. Kadence’s stock run fails that same audit on the same dismiss button, rendered by the equivalent block.
Core’s own defaults do not shrink that control. A third-party theme’s did. That turns the Kadence result from “a theme did something odd” into something sharper: a theme did something core does not.
Two caveats belong with every number above and I am not going to bury them. These baselines are flattering rather than typical. The page has hand-written CSS, no stock widgets or icon fonts, and none of the carousels and add-on packs a real site accumulates. Nobody has measured a real-world site of any of these kinds and nobody should guess. And the trimming is only defensible because nothing on this page needs it. Dequeuing a theme’s stylesheet removes its entire visual layer. On a site that actually uses the theme’s design, you get unstyled HTML. Do not copy that line onto a normal build.
What the platform does to your page behind your back
I saved each page through its own editor, then compared the stored data before and after. This is where the platforms genuinely differ, and it is invisible until it bites you.
Elementor writes your defaults into the database. A freshly composed page stores 2,345 bytes. One save with nothing edited expands it to 15,461. Every top-level control value is written out, including values identical to the defaults in the code. From that moment the page stops tracking your code. Change a default six months later and saved pages keep the old value while unsaved ones pick up the new one.
The block editor does the opposite. It omits values that match their default, so a round trip actually dropped an attribute that had been reverted. But it has its own quirk: editing one row of a repeating list serialises the entire list. Changing a single milestone title grew the stored content by 1,047 bytes, because all seven rows were written out.
Neither behaviour is wrong. Both are worth knowing before you hand a site over.
What you have to undo
Every build spent real time removing things the platform does by default. This list is the honest cost of a bespoke design on someone else’s theme.
Astra adds a scroll-to-top control that is on by default. With the theme’s CSS removed it lost its positioning and became a visible block, adding exactly 16 pixels to the page at every width. That build described it as sixteen pixels of arrow nobody could see, white on white.
Elementor’s containers write their flex gap into a custom property called --gap. The prototype has a design token by the same name. The collision silently collapsed a section’s padding to zero and cost 1,785 pixels of page height, with an identical DOM and no error anywhere.
WordPress itself injects image attributes late, and on one image it added a second copy of an attribute the prototype already had. Invalid HTML produced by WordPress, on a page where the markup was written by hand. The filter that does it runs at priority 12, so the obvious removal at the default priority silently does nothing.
And the block theme had the hardest time of all, which is the finding I did not anticipate.
The block theme is a different animal
Twenty Twenty-Five was meant to be the control group. It ships free with WordPress and needs no third-party theme or builder, and it hit zero divergence like the others. But it needed six separate escape hatches to get there, where Astra and Kadence needed none.
That is not a quality ranking and the build asked that it not be printed as one. It measures what each theme model permits. Effort had very little to do with it. Four of the six were WordPress’s own behaviour rather than the theme’s.
That is not an effort difference. It is structural:
A classic theme can avoid the wrappers; a block theme can only neutralise them.
A classic theme lets you own the page template outright and simply not emit the theme’s markup. A block theme gives you no such escape. The outer wrapper is hard-coded in WordPress core with no filter to remove it. A child theme cannot switch its parent’s styles off through settings, so 9,997 bytes of parent rules survive and have to be countered one at a time, with the body padding being the one that insets every full-bleed section.
Of the six escape hatches, two were the parent theme’s doing and four were core’s.
If you are building a bespoke design and want to stay in core WordPress, that is the trade: it works, it performs, and you will spend the difference fighting wrappers you cannot delete.
What it is actually like to edit
This is the part I cared most about, because it is the part a client lives with.
Every build had to expose every visible string, link, image, toggle and number as a real labelled control in the platform’s own editor. A wall of generic ACF fields would not have counted. Neither would a shortcode. That meant Divi modules in the Visual Builder, Elementor widgets in Elementor and registered blocks in the block editor. If the editing experience is not native to the platform, the comparison is meaningless.
That standard caught something. One build had quietly hard-coded its hero, the largest and most important section on the page, because splicing the site header into it was awkward. Ten blocks were fully editable and the eleventh, the one a client would want to change first, was not. It was fixed, and it is in the record because the fix only happened when somebody asked.
Two lessons came out of this that I will apply to client work.
Judge what a person can actually change. Field counts tell you almost nothing. A build reported 367 attributes before checking what that number counted. The real figure was 197, and the rest were added by WordPress itself.
Treat your defaults as content. They are what the client sees first and what they edit against.
And a warning worth more than either. Structural identifiers are not content. Two builds independently exposed an internal identifier as an editable text field, where changing it silently breaks a menu with no error at all. Both locked them afterwards. If you expose plumbing in an editor, someone will eventually type in it.
Where the accessibility scores mislead you
Five of the six builds scored below 100 on accessibility for most of this project, because they faithfully reproduced a contrast problem that exists in the original design. Divi was the exception, because of two things it shipped by default.
I had those two changes applied to the prototype itself, so every build inherited them. All six now score 100.
And 100 does not mean the page is accessible. It means every node the audit checked passed. Two elements on the page still fail the contrast standard and no automated audit flagged either. The tap targets are worse: the menu button, the dismiss control and the navigation items are all below the recommended minimum size, and the contrast fix does nothing about any of them.
If you take one thing from this section, take that. A row of perfect scores is a statement about the audit. Whether a person can use your site is a separate question, and that row does not answer it.
Which should you pick?
GeneratePress if you are porting a design you already own and you want the theme to get out of the way. Its payload costs nothing measurable, and swapping it out later is a couple of dozen lines. It gives you the least to remove.
Astra for the same job and the same result in speed, but budget the time to evict its defaults. In that build’s words, Astra was a good host, and it was still a host I spent the first ninety minutes evicting.
Kadence if you want the theme’s own tooling and you are willing to configure rather than replace. It is excellent at not being in the way. Be aware that its blocks generate a fresh identifier for every instance, so the same page built twice does not produce the same output. If reproducible builds matter to you, that is disqualifying. If they do not, it is irrelevant.
Elementor if the editor is the product you are buying, and you accept that its frontend payload costs eight points and a second of load time on a page that uses none of it. Elementor free was never the constraint. The paid tier would not have helped, because its header builder produces the wrong structure for this design. In that build’s words, Pro would have offered me a tool that produces the wrong DOM.
Divi if you want the fastest route to a strong Lighthouse score. It reproduced the design like the rest of them, and it is the only build here that took all four categories to 100.
Twenty Twenty-Five if you are porting a fixed design where fidelity is the requirement and the design is not going to be renegotiated in the browser. It hit zero differing pixels on a stack with no licence, no third-party code and no build step. In its own words, if you have a designer who has already decided what the page looks like and a developer who can write the block code, this is an excellent choice and the cheapest one available. There is no vendor here. The only dependency is WordPress, which matters if you need the result to still work in five years.
Not if you have no developer, and that build was blunt that this is the easy one to soft-pedal:
The editing experience is good because someone wrote 362 controls by hand. Out of the box, core gives you nothing resembling this. If nobody on the team can write PHP and enough JavaScript to build an inspector panel, the honest comparison is not Twenty Twenty-Five versus Divi, it is core blocks versus Divi, and core blocks will lose.
And not if you need to iterate on the design in the browser with a client watching. Every change here is a code change.
What this project does not tell you
I want to be straight about the limits, and the sharpest version of it came from the build with the most to lose by saying it.
Asked whether it would choose this stack again, Twenty Twenty-Five said yes for this brief and no for a normal one. For a marketing site where the design keeps moving and a non-developer needs to restructure pages, it would not recommend a page builder either. It would recommend a block theme built from core blocks with the theme’s own configuration doing real work, which is precisely what this build switched off.
That is worth sitting with. The main thing Twenty Twenty-Five is for, this project deliberately disabled. In that build’s words, a byte-exact port of a hand-authored prototype is close to the least representative task you could set a block theme.
The same caution applies to every result here. These are six ports of a finished design. Nobody designed a site in any of these themes, and that is what most people reading this are actually doing.
Two rankings, and they run almost opposite
Everything above measures one thing: what a platform costs you to host and how cheaply you can leave it. On that axis the order is clear.
Cheapest to run and leave. In order:
- GeneratePress
- Astra
- Core WordPress
- Kadence
- Elementor, a long way back
But that is not the question most people are deciding, and it is not the question I care about when I hand a site to a client. The second ranking is how good it is to actually work in, and it runs almost backwards.
GeneratePress is the clearest case. It won the first ranking outright, and here is how it describes its own editing experience:
It’s a content editor for a fixed design.
That is accurate and it is not a criticism. You can retype a heading, swap an image or add a timeline row. You cannot change the layout, the spacing or where anything sits, because the build gives the editor no design controls at all. Astra is the same, since both are the core block editor with custom blocks in it.
The thing that made those themes win the first ranking, that they get completely out of the way, is the same thing that makes them the weakest to work in. Lightness and capability are one axis pointed in two directions.
Where the real dangers are, and they are not where you would guess
The block editor has the worst one in this entire project. In the Site Editor, template editing sits next to content editing and almost nothing distinguishes them. A client following a back arrow ends up editing something that affects every page, on a screen that looks identical to the one they were just on.
And this build has a specific trap underneath that. Two blocks open and close the page’s main element between them, because a block theme has nowhere else to put it. In the list view they look like two ordinary blocks at opposite ends. If a client drags the footer above the final call to action, or deletes the announcement bar because they no longer want it, the document structure silently breaks. The page still renders. The landmark structure breaks, the skip link target moves and the hero sizes wrongly. There is no error message. The client sees a page that looks subtly wrong and has no way to connect it to what they did.
That build called it the single worst affordance in its own work and said it would not hand the site to a client without locking those two blocks first.
Elementor’s is quieter and still costly. Its containers write their layout gap into a property with the same name as one of the design’s own. The collision silently collapsed a section to zero padding and cost 1,785 pixels of page height, with an identical document and no error anywhere.
Astra’s is invisible. A control it ships switched on by default lost its positioning once the theme’s stylesheet came out, and added exactly sixteen pixels of white-on-white arrow to every page.
Kadence’s makes the page worse on an axis nobody checks. Its own button styling shrinks a control a single pixel under the accessibility minimum. Core’s defaults do not do that.
What I would actually build on, and where this stops being measurement
Everything to this point is measured and reproducible. What follows is my opinion, and I want the line between them to be obvious, because you should be able to take the numbers and reach a different conclusion than I did.
I build on Divi, and I am going to keep building on Divi.
The measurements say Divi is heavier than the lightweight themes. That is true, and it is the only thing the numbers hold against it. Here is why it wins for the work I do.
Divi’s gotchas are less dangerous than the alternatives’. Its real one is the Theme Builder, where a client can break the layout of every page at once. That is a serious risk and it is also a lockable one, which is the whole point: restrict who can reach it and the risk is gone. Compare that with a document structure a client can silently unbalance by dragging a block, or a page that comes out 1,785 pixels short with no error. Divi’s problems are visible, cosmetic, and I know how to work around every one of them. The others’ problems are invisible until something is already wrong.
The builder is genuinely learnable by people who do not build websites. That matters more than any Lighthouse point when the site is going to be maintained by an office manager. I have watched clients pick it up. I have not watched a client pick up the Site Editor, and having now seen what that build had to do to make it safe, I would not want to.
And it is buy once, own it. Not a subscription that gets more expensive every year across every site you have ever built. Over a book of client sites that is not a small difference.
Where Divi will hurt you, and it is not the page builder
This is the part people get wrong, so it is worth being specific. The dangerous surface in Divi is the Theme Builder. The page builder itself is safe to hand over.
A client loose in the Theme Builder can break the layout of every page on the site at once, because that is exactly what it is for. Lock it down before handover. Restrict who can reach it, and treat any template as a developer-owned object rather than something the client edits.
That single piece of advice is worth more than the difference between any two themes in this article.
Where I landed
If I am handed a finished design and asked to put it into WordPress, I care about one property above all others: how cheaply can I switch the platform off?
Every build here arrived at the same place independently. Each one dequeued its own platform’s frontend payload to reach its numbers. Six builds, six different stacks, and all six concluded the platform is best when switched off.
That is a narrow claim and I want to keep it narrow. It says the platform that costs least to remove wins for this job. It says nothing about which is the better tool for designing something new, which is what most people reading this are actually doing.
For that job, the honest answer is that I did not test it, and neither has anyone else who publishes a theme comparison built on feature tables.
If you would rather not run this experiment yourself, that is the work I do. Zealous Sites builds on whichever theme a client wants and prefers Divi, and there is more on that on the Divi developer page.
What do these six actually cost in 2026?
Five of the six have a free tier, and every build in this project ran on one. Here is what the paid tiers cost if you decide you want them.
| Platform | Free tier | Paid | Sites covered |
|---|---|---|---|
| Divi | none | $89/yr, or $249 once | unlimited |
| Elementor | yes | from $60/yr | 1, or 3 at $108/yr |
| GeneratePress | yes | $59/yr | up to 500 |
| Astra | yes | $69/yr, or $249 once | 3 |
| Kadence | yes | $99/yr | 1 |
| Twenty Twenty-Five | ships with WordPress | nothing to buy | unlimited |
Two things in that table matter more than the rest.
The first is the licence, which is where the real money is. Divi and Twenty Twenty-Five are the only two rows covering unlimited sites. GeneratePress’s 500 is effectively unlimited for a studio. Everything else is priced per site, so the bill scales with the number of clients you serve.
The second is that Divi is the only platform here selling a one-time price that covers unlimited websites. Astra sells a lifetime too, for three sites at a time. Kadence and Elementor and GeneratePress are subscriptions only, which means the day you stop paying is the day your tooling starts ageing.
All prices checked on the vendors’ own pages on 13 September 2026: Divi, Elementor, GeneratePress, Astra, Kadence and Twenty Twenty-Five. Kadence’s moved during this project: kadencewp.com/pricing now returns a redirect to Liquid Web.
WordPress theme questions, answered
Drafted from the four builds that answered Part C. Carry FAQPage schema, as the two live comparison posts do.
Which WordPress theme is fastest?
On this page, the theme was almost never the bottleneck. What mattered was what each platform ships on its own before you write any code. Elementor’s payload cost eight performance points and 1.1 seconds. Kadence’s cost one point. GeneratePress and Astra cost nothing measurable. If speed is your priority, the question to ask is not which theme is fastest but how much of it you can switch off.
Does the theme you pick actually change how your site looks?
Not if you bring your own design. All six builds reproduced the same design with zero differing pixels. Where the theme shows up is in what you have to remove first: a scroll-to-top control that added exactly 16 pixels, a custom property that collided with the design’s own and cost 1,785 pixels of page height, a stylesheet that broke a mobile layout by 13.83% when left in place.
Do you need a paid theme or a paid page builder?
Not for a build like this one. Every build here ran on a free tier. In one case the paid tier would actively have made things worse, because its header builder produces the wrong page structure for this design. Buy the paid tier for features you will actually use. A layout problem is usually cheaper to solve in a template. For reference, the cheapest paid tier in this comparison is GP Premium at $59 a year and the dearest single product is Divi Pro at $277.
Can a non-developer edit a site built this way?
Only if it was built for that, and the theme has almost nothing to do with it. The editing experience comes entirely from the blocks or widgets whoever built your site registered. One build here had ten fully editable sections and a hard-coded hero, which is the section a client would want to change first. Ask to see the editor before you accept a site. The front end tells you nothing about it.
Which theme should I choose for a new site?
This project cannot answer that honestly, and I would rather say so. Every build here ported a finished design into a theme. Nobody designed a site in one, which is what most people are actually doing. For porting, the theme that costs least to remove wins. For designing, you would need a different test than this one.
Would you rather just hand this to someone?
That is the job. Zealous Sites has been building websites since 2010, which is more than sixteen years of handing finished sites to people who then have to live in them. We will work in whichever theme you want to use, and Divi is what we reach for first.
New sites start at $2,400, and you get a fixed price to approve before anything starts, so there’s no hourly meter running while we work out the scope. You can scope your own project on the pricing page, see what we have built, or tell us what you have in mind.